FR 2934910 A1 20100212 FR 0804450 A 20080805 PROCÉDÉ DE SÉCURISATION D'UNE TRANSACTION EXÉCUTÉE AU MOYEN D'UN DISPOSITIF PORTABLE PROGRAMMABLE La présente invention concerne un dispositif de transaction pour réaliser une transaction avec un dispositif externe par une liaison de communication. La présente invention concerne également un procédé de sécurisation d'une transaction entre un dispositif de transaction et un dispositif externe, en particulier une transaction exécutée avec un dispositif portable programmable. De nos jours, il est possible de réaliser des transactions grâce à des dispositifs portables communs comme par exemple des téléphones portables ou des assistants numériques personnels (PDA). En effet, les moyens de communication sans fil ou sans contact peuvent facilement être intégrés dans de tels dispositifs portables pour établir une communication sans fil ou sans contact avec un dispositif externe, afin de réaliser des transactions. La figure 1 illustre un exemple d'un dispositif de transaction conventionnel 1 doté de fonctionnalités de communication NFC (Near Field Communication ou communication à champ proche). Essentiellement, le dispositif de transaction comprend un contrôleur de communication NFC 10, un processeur d'application 20, un dispositif d'affichage 31, et un dispositif d'entrée 32 relié au processeur d'application 20. Le contrôleur de communication NFC 10 comprend une bobine d'antenne permettant d'établir une liaison de données sans contact CDL avec un dispositif NFC externe 40, par exemple un terminal de paiement ou un distributeur. Le dispositif externe 40 est également équipé d'une bobine d'antenne et le dispositif externe et 2 2934910 le contrôleur de communication NFC peuvent tous deux échanger des données par couplage inductif. Dans le dispositif de transaction 1, le contrôleur de communication 10 est couplé avec au moins une mémoire 5 de données et de programme 11 dans laquelle un programme exécuté par le contrôleur est stocké. Le processeur d'application 20 est couplé avec au moins une mémoire de données et de programme 21 dans laquelle des programmes d'application sont stockés. 10 En outre, le dispositif de transaction 1 comprend typiquement une autre interface de communication 22 par laquelle il peut recevoir des programmes d'application APP stockés dans la mémoire 21 et exécutés par le processeur d'application 20. On suppose ici qu'au moins 15 un programme d'application APP a été téléchargé via la liaison de données sans contact CDL, afin de gérer une transaction. De par sa nature, un tel dispositif portable commun est bien moins sécurisé qu'un dispositif de paiement 20 sécurisé et certifié, comme ceux que l'on trouve dans les magasins ou les banques. En particulier, le processeur d'application 20, dans lequel des programmes d'application APP peuvent être téléchargés et installés à l'aide de l'interface de communication 22, peut contenir 25 des logiciels malveillants. Ces logiciels malveillants peuvent être conçus pour intercepter ou corrompre des données de transaction dans les applications payantes comme le paiement d'une facture, un retrait d'argent dans un distributeur, un paiement pour accéder à un endroit 30 payant (métro, musée, boîte de nuit,...), etc. Par conséquent, une telle corruption de données de transaction peut conduire au paiement d'une somme plus importante que celle attendue par l'utilisateur. A titre d'exemple, une transaction est initiée et une connexion (liaison de données CDL) est établie entre le dispositif de transaction 1 et le dispositif externe 40. Le dispositif externe envoie les données de transaction au dispositif de transaction. La somme est affichée sur le dispositif d'affichage 31 et l'utilisateur est requis de confirmer s'il accepte de payer le montant indiqué en entrant un accusé via le dispositif d'entrée 32 (par exemple en choisissant � Oui � ou � Non � ou en entrant un code personnel à titre d'acquiescement, ou les deux). Le processeur Io d'application envoie ensuite cet accusé au dispositif externe afin de terminer la transaction. Les logiciels malveillants peuvent corrompre le programme d'application APP de telle sorte que la transaction est exécutée avec des données de transaction différentes de celles 15 affichées et/ou acceptées par l'utilisateur. Par exemple, une transaction pour une somme de 1000 { peut être initiée par le logiciel malveillant alors qu'une somme de 10 { est affichée à l'utilisateur. Dans ce cas, l'utilisateur paie les 1000 { au lieu des 10 { qu'il a 20 accepté de payer. Il peut donc être souhaité de prévoir un procédé de sécurisation d'une transaction exécutée avec un dispositif de transaction pouvant être corrompu par un logiciel malveillant, en particulier une transaction 25 exécutée avec un dispositif portable programmable. Un mode de réalisation de l'invention concerne un procédé de sécurisation d'une transaction entre un dispositif de transaction et un dispositif externe, le dispositif de transaction comprenant un contrôleur de 30 communication, un processeur d'application, et un dispositif d'entrée, la transaction comprenant l'échange de données d'application entre le dispositif de transaction et le dispositif externe, et une étape d'émission de données de transaction du dispositif de 35 transaction vers le dispositif externe ou du dispositif externe vers le dispositif de transaction. Le procédé de sécurisation comprend les étapes consistant à demander à l'utilisateur d'entrer des données de transaction approuvées via le dispositif d'entrée, surveiller les données de transaction à envoyer au dispositif externe ou reçues du dispositif externe, et empêcher les données de transaction d'être envoyées au dispositif externe si elles sont différentes des données de transaction approuvées, ou rejeter les données de transaction reçues si elles sont différentes des données de transaction approuvées. Selon un mode de réalisation, le procédé comprend une étape consistant à interrompre la transaction au lieu d'empêcher les données de transaction d'être envoyées ou de rejeter les données de transaction reçues. Selon un mode de réalisation, le procédé comprend les étapes consistant à : capturer et mémoriser les données de transaction approuvées entrées par l'utilisateur, au moyen du contrôleur de communication; surveiller les données de transaction à envoyer au dispositif externe ou reçues du dispositif externe, au moyen du contrôleur de communication; et configurer le contrôleur de communication de telle sorte qu'il refuse d'envoyer des données de transaction différentes des données de transaction approuvées, ou qu'il rejette les données de transaction reçues qui sont différentes des données de transaction approuvées. Selon un mode de réalisation, le procédé comprend une étape consistant à appliquer au contrôleur de communication une commande lui demandant de capturer et mémoriser les données de transaction approuvées, avant de demander à l'utilisateur d'entrer des données de transaction approuvées. Selon un mode de réalisation, le procédé comprend 35 les étapes consistant à : appliquer une commande spécifique au contrôleur de communication lorsque des données de transaction doivent être envoyées au dispositif externe, et fournir au contrôleur de communication les données de transaction à envoyer; configurer le contrôleur de communication de telle sorte qu'en réponse à la commande il surveille les données de transaction spécifique, puis envoie les données de transaction au moyen d'une encapsulation spécifique ou de données d'accompagnement si les données de transaction à Io envoyer sont identiques aux données de transaction approuvées. Selon un mode de réalisation, le procédé comprend une étape consistant à configurer le dispositif externe de telle sorte qu'il refuse les données de transaction 15 qui ne sont pas encapsulées dans des données d'encapsulation spécifiques ou accompagnées de données d'accompagnement spécifiques Selon un mode de réalisation, le procédé comprend les étapes consistant à : envoyer des données 20 d'application au dispositif de transaction au moyen d'une trame de données spécifique ; en réponse à la réception de la trame de données spécifique, comparer les données de transaction présentes dans la trame spécifique aux données de transaction approuvées, au moyen du contrôleur 25 de communication. Un mode de réalisation de l'invention concerne également un dispositif de transaction comprenant un contrôleur de communication, un processeur d'application pour réaliser des transactions avec un dispositif externe 30 par l'intermédiaire du contrôleur de communication, et un dispositif d'entrée, le dispositif étant configuré pour : demander à l'utilisateur d'entrer des données de transaction approuvées via le dispositif d'entrée lors d'une transaction; surveiller les données de transaction 35 à envoyer au dispositif externe ou reçues du dispositif externe; et empêcher les données de transaction d'être envoyées au dispositif externe si elles sont différentes des données de transaction approuvées, ou rejeter les données de transaction reçues si elles sont différentes des données de transaction approuvées. Selon un mode de réalisation, le dispositif de transaction est configuré pour interrompre une transaction lorsque les données de transaction à envoyer sont différentes des données de transaction approuvées, ou lorsque les données de transaction reçues sont différentes des données de transaction approuvées. Selon un mode de réalisation, le contrôleur de communication est configuré pour : capturer et mémoriser les données de transaction approuvées entrées par l'utilisateur ; surveiller les données de transaction à envoyer au dispositif externe ou reçues du dispositif externe ; et refuser d'envoyer des données de transaction différentes des données de transaction approuvées, ou rejeter des données de transaction reçues différentes des données de transaction approuvées. Selon un mode de réalisation, le processeur d'application est configuré pour demander à l'utilisateur d'entrer des données de transaction approuvées et pour appliquer au contrôleur de communication une commande lui demandant de capturer et de mémoriser les données de transaction approuvées, avant de demander à l'utilisateur d'entrer des données de transaction approuvées. Selon un mode de réalisation, le processeur d'application est configuré pour appliquer une commande spécifique au contrôleur de communication lorsque des données de transaction doivent être envoyées au dispositif externe, et fournir au contrôleur de communication les données de transaction à envoyer, et le contrôleur de communication est configuré pour surveiller les données de transaction en réponse à la commande spécifique, puis envoyer les données de transaction au moyen d'une encapsulation spécifique ou de données d'accompagnement si les données de transaction à envoyer sont identiques aux données de transaction approuvées. Selon un mode de réalisation, le contrôleur de communication est configuré pour, en réponse à la réception d'une trame de données spécifique comprenant des données de transaction, comparer les données de transaction présentes dans la trame spécifique aux données de transaction approuvées. Selon un mode de réalisation, le contrôleur de communication est un contrôleur NFC. Selon un mode de réalisation, le processeur d'application est un processeur de bande de base d'un téléphone portable ou le processeur principal d'un assistant numérique personnel. Un mode de réalisation de l'invention concerne également un système de transaction, comprenant un dispositif de transaction tel que décrit ci-dessus, et un dispositif externe configuré pour réaliser une transaction avec le dispositif de transaction. Selon un mode de réalisation, le dispositif externe est configuré pour refuser des données de transaction qui ne sont pas encapsulées dans des données d'encapsulation spécifiques ou accompagnées de données d'accompagnement spécifiques. Selon un mode de réalisation, le dispositif externe est configuré pour envoyer des données d'application au dispositif de transaction au moyen d'une trame de données spécifique. Des modes de réalisation de l'invention seront décrits plus en détails dans la description qui suit, faite à titre non limitatif en relation avec les figures jointes parmi lesquelles : - La figure 1 précédemment décrite illustre une architecture conventionnelle d'un dispositif de transaction commun, - La figure 2 illustre un mode de réalisation d'un dispositif de transaction selon la présente invention, - Les figures 3A et 3B sont des organigrammes simplifiés décrivant un mode de réalisation d'un procédé de sécurisation d'une transaction selon la présente invention, - La figure 4 est un organigramme simplifié décrivant un second mode de réalisation d'un procédé de sécurisation d'une transaction selon la présente invention, et - La figure 5 est un organigramme simplifié décrivant une variante du mode de réalisation illustré sur les figures 3B et 4, - Les figures 6A et 6B sont des organigrammes simplifiés décrivant un troisième mode de réalisation d'un procédé de sécurisation d'une transaction selon la présente invention, - La figure 7 illustre un autre mode de réalisation d'un dispositif de transaction selon la présente invention. La figure 2 illustre schématiquement, sous forme de blocs, un mode de réalisation d'un dispositif de transaction 2 selon la présente invention, par exemple un téléphone portable ou un PDA. A l'instar du dispositif de transaction 1 décrit ci-dessus en relation avec la figure 1, le dispositif de transaction 2 comprend un contrôleur de communication P1 et au moins un processeur d'application P2. Le contrôleur de communication P1 est par exemple un contrôleur NFC équipé d'une bobine d'antenne capable d'envoyer des données à et de recevoir des données d'un dispositif externe ED, via une liaison de données sans contact CDL. Le dispositif ED peut être tout type de portail interactif NFC et est également équipé d'une bobine d'antenne. Le contrôleur de communication P1 est couplé avec au moins une mémoire de données et de programme PMEM1 dans laquelle un programme exécuté par le contrôleur de communication est stocké. De la même façon, le processeur d'application P2 est couplé à au moins une mémoire de données et de programme PMEM2, et peut par exemple être le processeur de bande de base d'un téléphone portable ou le processeur principal d'un PDA. D'autres processeurs hôtes, non illustrés, comme une SIM (Subscriber Identity Module) ou un autre élément sécurisé peuvent être inclus dans le dispositif de transaction et connectés au contrôleur de communication Pl. Le dispositif de transaction 2 comprend également un dispositif d'affichage DD et un dispositif d'entrée ID qui sont liés au processeur d'application P2. Le dispositif d'entrée ID peut être par exemple un clavier, un microphone, une entrée biométrique, une combinaison de ces éléments, ou tout autre moyen permettant à l'utilisateur d'entrer des informations. Enfin, le dispositif de transaction comprend également au moins une interface de communication, comme par exemple une interface sans fil (Wifi), une interface radio du type GSM, un port USB, un port Ethernet, etc., ou une combinaison de ces éléments, qui est représentée schématiquement en tant qu'interface de communication CI du processeur d'application 20. Au moyen de cette interface, le dispositif de transaction 2 peut recevoir des programmes d'application APP qui sont stockés dans la mémoire PMEM2 et exécutés par le processeur d'application 20. Comme indiqué ci-dessus, un programme d'application peut contenir un logiciel malveillant conçu pour corrompre des données de transaction. D'autre part, la mémoire PMEM1 est réputée être 35 incorruptible pour des logiciels malveillants en ce qu'elle est programmée en usine et n'est pas accessible pour l'utilisateur. Des modes de réalisation de la présente invention se basent sur cette observation, et s'appuient sur le contrôleur de communication Pl pour vérifier que les données de transaction échangées entre le processeur d'application P2 et le dispositif externe ED ne sont pas corrompues. Selon un aspect de modes de réalisation de la présente invention, le contrôleur P1 est également relié au dispositif d'entrée ID de telle sorte qu'il puisse également capturer des données entrées par l'utilisateur. Par exemple, le dispositif d'entrée ID et le processeur d'application P2 peuvent tous deux comprendre une interface UART (Universal Asynchronous Receiver/Transmitter) Il, I2 respectivement, les deux interfaces étant interconnectées au moyen de deux conducteurs Tx, Rx. Dans ce cas, le contrôleur de communication Pl comprend également une interface UART I3 qui est au moins connectée au connecteur Rx de l'interface I1, afin de recevoir des données émises par le dispositif d'entrée ID. Selon un second aspect de modes de réalisation de la présente invention, lorsqu'une transaction impliquant des données de transaction est exécutée, l'utilisateur d'entrer les données de transaction, par exemple la somme qu'il souhaite payer, qui seront désignées dans ce qui suit � données de transaction approuvées � ATD (Acknowledged Transaction data). Selon un troisième aspect de modes de réalisation de la présente invention, le contrôleur de communication Pl est configuré pour surveiller des données de transaction TD envoyées par le dispositif externe ED ou reçues par l'intermédiaire du dispositif externe, et intervenir dans la transaction en cours si les données de transaction TD sont différentes des données de transaction approuvées ATD entrées par l'utilisateur. Comme on le verra ci-dessous au moyen d'exemples, � l'intervention � du contrôleur de communication peut consister à interrompre la transaction, à refuser d'envoyer des données au dispositif externe, etc., et plus généralement à réaliser toute action dont le but est de protéger l'utilisateur de transactions impliquant des données de transaction différentes de celles approuvées par l'utilisateur. Différents exemples d'implémentation de ces aspects de modes de réalisation de la présente invention vont maintenant être décrits en référence aux figures 3A, 3B, 4, 5, 6A, et 6B. Dans ces modes de réalisation exemplatifs, le contrôleur P1 reçoit des trames de données entrantes IDF dans un format du type � {x[IAD]x} � envoyées par le dispositif externe ED, où IAD représente des données d'application entrantes à l'attention du processeur d'application P2 et � x � des données d'encapsulation utilisées par le contrôleur de communication P1 et le dispositif externe ED pour gérer la communication. Par exemple, les données d'encapsulation peuvent comprendre un début de trame SOF (Start of Frame), une fin de trame EOF (End Of Frame), des commandes NFC, une signature CRC (Cyclic Redundancy Check, ou contrôle de redondance cyclique), etc. Les données d'application entrantes IAD, inclues dans les trames de données entrantes IDF, sont désencapsulées par le contrôleur de communication P1 et fournies au processeur d'application P2. De la même façon, le contrôleur P1 envoie au dispositif externe ED des trames de données sortantes ODF dans un format du type � {x[OAD]x} �, où OAD représente des données d'application sortantes et � x � des données d'encapsulation. Les données d'application sortantes OAD sont fournies par le processeur d'application P2 au contrôleur de communication P1 au moyen de commandes du type SEND DATA [OAD]. Afin de simplifier le langage de la présente description, le contrôleur de communication sera appelé � Pl �, le processeur d'application � P2 �, et le dispositif externe � ED �. Une trame de données entrantes sera appelée une � IDF � et une trame de données sortantes une � ODF �. Les données d'application entrantes seront appelées des � IAD � et les données d'application sortantes des � OAD �. Les données de transaction approuvées seront appelées des � ATD �. Premier exemple de réalisation La figure 3A est un organigramme simplifié décrivant des étapes de traitement exécutées par Pl lors d'une transaction. On observe différentes boucles de traitement : - une boucle de traitement LOI comprenant des étapes S01 et S02, - une boucle de traitement L02 comprenant des étapes S03 20 et SO4, - une boucle de traitement L03 comprenant des étapes S05 et S06, et - une boucle de traitement L04 comprenant des étapes S07 à 511. 25 Les boucles LOI et L02 comprennent des étapes de traitement conventionnelles et les boucles L03 et L04 sont prévues pour implémenter des aspects de ce mode de réalisation de l'invention. Ces boucles de traitement sont rattachées à une étape d'attente initiale S00 dans 30 laquelle le contrôleur Pl attend une trame de données entrantes IDF de ED ou une commande venant de P2. La boucle de traitement LOI est exécutée lorsque Pl reçoit une IDF de ED, c'est-à-dire des données d'application entrantes encapsulées {x[IAD]x}, à l'étape 01. Puis Pl désencapsule les IAD et les envoie à P2 à l'étape S02. La boucle de traitement L02 est exécutée lorsque Pl reçoit une commande SEND DATA [OAD] envoyée par P2, à l'étape S03. Puis Pl envoie à ED une ODF comprenant les OAD encapsulées {x[OAD]x}, à l'étape 04. La boucle de traitement L03 est exécutée lorsque Pl reçoit une commande spécifique ATDR (Agreed Transaction Data Request, soit Requête en communication de données de Io transaction approuvées) envoyée par P2, à l'étape S05. Cette commande informe Pl que P2 va demander à l'utilisateur d'entrer les ATD au moyen du dispositif d'entrée ID. En réponse à cette commande, Pl écoute le dispositif d'entrée ID puis capture et mémorise les 15 données fournies par le dispositif ID en tant que données de transaction approuvées ATD entrées par l'utilisateur. La boucle de traitement L04 est exécutée lorsque P1 reçoit de P2 une commande spécifique SEND_TD [TD] comprenant des données de transaction TD, à l'étape S07. 20 Cette commande demande à pl d'envoyer à ED une ODF spécifique dans un format du type {y[TD]y} ou {y[TD]x} ou {x[TD]y}, où � y � représente des données encapsulées différentes des données d'encapsulation � x � habituelles. 25 Lorsqu'une telle commande est reçue, Pl vérifie d'abord si les ATD ont été mémorisées (étape S08), c'est-à-dire si la boucle de traitement L03 a déjà été exécutée. Deux situations peuvent se produire : 1) Si Pl ne détient pas de données de transaction 30 approuvées mémorisées ATD, la commande reçue SEND_TD est considérée comme suspecte et est rejetée. De plus, si l'on souhaite un niveau de sécurité supérieur, la réception d'une telle commande lorsqu'aucune donnée de transaction approuvée n'a été mémorisée peut être 35 considérée comme une brèche inacceptable dans la sécurité de la transaction et par conséquent P1 peut être configuré pour provoquer une interruption complète de la transaction au lieu de simplement rejeter la commande. Ainsi, P1 passe à l'étape S10 dans laquelle il envoie à P2 l'information indiquant qu'il refuse d'envoyer l'ODF contenant les données de transaction non approuvées TD ou dans laquelle il interrompt complètement la transaction. Puis P1 retourne à l'étape d'attente SOO. 2) Si les données de transaction approuvées ATD ont été mémorisées, Pl vérifie si les données de transaction TD présentes dans la commande sont identiques aux données ADT. Si elles ne sont pas identiques, P1 passe à l'étape S10 pour indiquer à P2 qu'il refuse d'envoyer l'ODE contenant les données de transaction non approuvées TD ou pour interrompre la transaction. Puis Pl retourne à l'étape d'attente SOO. Si les données de transaction approuvées ATD et les données de transaction TD sont identiques, P1 envoie l'ODE à ED sous la forme {y[TD]y} ou {y[TD]x} ou {x[TD]y}, puis retourne à l'étape SOO. L'homme de l'art notera qu'un mécanisme de sécurité supplémentaire peut être prévu dans le dispositif externe ED pour garantir qu'aucune donnée de transaction TD ne sera acceptée si elle n'est pas encapsulée dans une trame de données contenant les données d'encapsulation spécifiques � y �. Dans un autre mode de réalisation, il peut être prévu que le terminal ED génère une valeur aléatoire ou � jeton � au début d'une transaction et l'envoie à pl, et que les données de transaction ne sont acceptées par ED que si elles sont accompagnées de ce � jeton �. La figure 3B est un organigramme simplifié décrivant des étapes de traitement exécutées par P2 lors d'une transaction, ces étapes correspondant à celles qui viennent d'être décrites en relation avec la figure 3A. Des étapes S20 à S27 sont représentées. A l'étape S20, P2 attend des données d'application entrantes IAD, qui sont transmises par Pl après désencapsulation (étape S02, figure 3A). Lorsque les IAD sont reçues, P2 passe à l'étape S21 dans laquelle il analyse les IAD et vérifie si les données de transaction TD sont demandées par ED. Deux situations peuvent se produire : 1) Si à cette étape de la transaction aucune donnée de transaction n'est exigée par ED, P2 passe à l'étape S22 au cours de laquelle il traite les IAD et forme des données d'application sortantes OAD à l'attention de ED. Ce traitement des IAD, jusqu'à la formation des OAD, peut comprendre différentes sous-étapes qui ne sont pas illustrées pour simplifier l'organigramme. En particulier, ces sous-étapes peuvent comprendre l'affichage de différentes informations et/ou données par l'utilisateur au moyen du dispositif d'affichage DD et la capture de données entrées par l'utilisateur au moyen du dispositif d'entrée ID. Dans la mesure où les données entrées par l'utilisateur ne sont pas des données de transaction sensibles, il n'est pas nécessaire que Pl soit impliqué dans ce processus. Ensuite, à l'étape S23, P2 envoie la commande SEND DATA [OAD] à pl (qui est traitée par P1 aux étapes S03, SO4, figure 3A) puis P2 retourne à l'étape d'attente S20. 2) Si les IAD contiennent une requête de transmission de données de transaction TD, P2 passe à l'étape S24 au cours de laquelle il envoie la commande ATDR à pl (Cf. étape S05 de la figure 3A). Puis P2 passe à l'étape S25 au cours de laquelle il utilise le dispositif d'affichage DD pour demander à l'utilisateur d'entrer les données de transaction approuvées ATD. A l'étape S26, qui est exécutée simultanément à l'étape S06 de la figure 3A, P2 écoute le dispositif d'entrée ID puis capture et mémorise les données de transaction approuvées ATD. A l'étape S27, qui correspond à l'étape S07 de la figure 3A, P2 envoie la commande SEND_TD [TD] à pi. Les données de transaction TD incluses dans cette commande sont supposées être les données de transaction approuvées ATD entrées par l'utilisateur. Si un logiciel malveillant dans la mémoire PMEM2 de P2 essaye de corrompre les données de transaction présentes dans la commande SEND TD, le contrôleur de communication détectera les données de transaction corrompues à l'étape S08 ou S09 de la figure 3A. Second exemple de réalisation Le processus de transaction qui vient d'être décrit comprend une confirmation des données de transaction par l'utilisateur à l'étape S25. La figure 4 est un organigramme simplifié illustrant des étapes de traitement exécutées par P2 dans un second mode de réalisation du procédé de sécurisation d'une transaction selon la présente invention. Cet organigramme est identique a l'organigramme de la figure 3B, sauf que les étapes S21 et S25 sont remplacées par les étapes S21' et S25', respectivement. Dans ce mode de réalisation, le dispositif externe ED demande simplement à l'utilisateur d'indiquer les données de transaction impliquées dans la transaction en cours. Cela peut se produire par exemple lorsque le dispositif de transaction est utilisé pour retirer de l'argent à un distributeur sans demander à l'utilisateur d'entrer le montant à retirer sur un dispositif d'entrée du distributeur. Dans ce cas, le dispositif d'entrée ID du dispositif de transaction est utilisé comme dispositif d'entrée du distributeur. Ainsi, à l'étape S21', les IAD reçues par P2 contiennent uniquement une requête demandant que les données de transaction impliquées dans la transaction soient communiquées au dispositif externe. A l'étape S25', P2 demande à l'utilisateur d'entrer les données de transaction souhaitées au lieu de lui demander de confirmer les données de transaction. Il apparaîtra clairement à l'homme de l'art que différentes variantes des modes de réalisation décrits ci-dessus peuvent être prévues. Par exemple, tel qu'illustré sur la figure 5, le processeur peut retourner à l'étape d'attente S20 après avoir capturé les ATD à l'étape S26, au lieu de passer à l'étape S27. Dans ce cas, les étapes S24-S26 peuvent être exécutées à l'avance, avant que P2 ne reçoive de ED une requête de confirmation des TD (étape S21) ou une requête d'envoi des TD (étape S21'), et l'étape S27 peut être exécutée lorsque P2 reçoit la requête de confirmation des TD (étape S21) ou d'envoi des TD (étape S21'). Troisième exemple de réalisation Les figures 6A et 6B sont des organigrammes simplifiés illustrant un mode de réalisation de la présente invention en relation avec les spécifications de paiement � EMV Book 3 � (http://www.emvco.com/documents/specification/view/EMVv4. 1Book3ApplicationSpecification.pdf). La figure 6A illustre des étapes de traitement exécutées par le contrôleur de communication Pl lors d'une transaction EMV comprenant des aspects du procédé de la présente invention. Dans ce mode de réalisation, le dispositif de transaction est utilisé comme carte de paiement compatible avec les spécifications EMV. On suppose que le dispositif externe ED est également compatible avec les spécifications EMV et est par exemple un terminal EMV. Ce mode de réalisation comprend l'utilisation d'une chaîne de données spécifique appelée � PDOL � (Processing Options Data Object List) qui est envoyée au dispositif externe ED par le dispositif de transaction pour définir la structure des champs présents dans une commande appelée � Get Processing Options � qui doit être envoyée par le dispositif externe pour communiquer les données de transaction. Comme défini dans les spécifications EMV, PDOL est une liste de balises et de longueurs d'éléments de données internes au dispositif, exigée par le dispositif de transaction pour traiter la commande Get Processing Options. L'organigramme de la figure 6A contient les boucles de traitement LOI, L02, et L03 qui ont été décrites ci- dessus en relation avec la figure 3A, ainsi que des boucles de traitement L04, L05 et L40. La boucle L04 comprend des étapes 5107 et 5108. A l'étape 5107, P1 reçoit une commande SELECT PPSE (� Proximity Payment Systems Environment �) envoyée par ED. Cette commande indique que la transaction a commencé. A l'étape 5108, Pl envoie la commande SELECT à P2 pour informer P2 que la transaction est engagée. La boucle L05 comprend des étapes 5109 et 5110. A l'étape S109, Pl reçoit la commande SEND PDOL envoyée par P2. A l'étape 5110, Pl analyse et mémorise la structure de données présente dans le champ PDOL puis envoie le champ POOL à ED, par exemple au moyen d'une ODF du type {x[PDOL]x}. La boucle L40 remplace la boucle L04 précédemment décrite et contient des étapes de sécurité selon ce mode de réalisation de l'invention. Contrairement à la boucle L04 dont le but est de détecter une corruption des données de transaction TD en surveillant les données d'application sortantes OAD qui forment ou qui comprennent de telles données de transaction TD, le but de la boucle L40 est de détecter une corruption des données de transaction en surveillant les données d'application entrantes IAD présentes dans la commande Get Processing Options envoyée par le dispositif externe ED. Plus particulièrement, la boucle L40 comprend une étape 5111 au cours de laquelle Pl reçoit la commande Get Processing Options de ED, et une étape 5112 au cours de laquelle Pl détermine si la structure de données POOL a été mémorisée au préalable. Si la structure de données PDOL n'a pas été mémorisée, P1 passe à une étape 5113 au cours de laquelle il interrompt la transaction ou rejette la commande Get Processing Options, par exemple en indiquant à ED que les données de transaction de la commande Get Processing Options sont invalides. Si la structure de données PDOL a été mémorisée, P1 passe à une étape 5114 au cours de laquelle il analyse les données présentes dans la commande Get Processing Options afin d'extraire, par exemple, le montant de la transaction et la devise impliquée dans la transaction, représentant les données de transaction TD. Par exemple une valeur � Ox9F02 � indique le montant de la transaction et une valeur � Ox5F2A � indique la devise de la transaction. Puis, à l'étape S115, P1 vérifie si les données de transaction approuvées ATD ont été mémorisées, c'est-à-dire si la boucle L03 comprenant l'étape S05 (réception de la commande ATDR envoyée par P2) et l'étape S06 (écoute de ID, capture et mémorisation des ATD) a déjà été exécutée. Si l'étape S06 n'a pas été exécutée, Pl passe à l'étape S113 afin d'interrompre la transaction ou de rejeter la commande Get_Processing_Options. Si les données de transaction ATD ont été mémorisées, P1 passe à l'étape S116 au cours de laquelle il vérifie si les données de transaction TD (ici le montant et la devise) sont égales aux données de transaction approuvées ATD. Si elles ne sont pas égales, Pl passe à l'étape 5113 afin d'interrompre la transaction ou de rejeter la commande Get Processing Options. Si elles sont égales, Pl envoie la commande Get Processing Options à P2 pour que P2 puisse finaliser la transaction. La figure 6B est un organigramme illustrant des étapes de traitement exécutées par le processeur d'application P2 lors de la même transaction EMV. Lors d'étapes préliminaires non illustrées sur la figure 6B, le montant et la devise de la transaction, c'est-à-dire les données de transaction, sont communiquées verbalement ou visuellement à l'utilisateur par un détaillant ou un commerçant. Puis, l'utilisateur active le programme d'application de transaction dans le dispositif de transaction, par exemple en appuyant sur un bouton spécifique du dispositif de transaction ou en sélectionnant une option dans le menu général affiché par le dispositif d'affichage DD. Cette action conduit le processeur P2 à activer le programme d'application lors d'une étape S30. Puis P2 envoie la commande ATDR à pl lors d'une étape S31. Lors d'une étape suivante S32, P2 demande à l'utilisateur d'entrer les données de transaction approuvées ATD. Puis, lors d'une étape S34, P2 écoute ID, puis capture et mémorise les données fournies par ID en tant que données de transaction approuvées ATD entrées par l'utilisateur (l'étape S33 se déroule simultanément à l'étape S06 sur la figure 6A). Puis, lors d'une étape suivante S34, P2 attend la commande Select PPSE envoyée par ED qui confirme le début de la transaction. On suppose ici que l'utilisateur, après avoir activé le programme de transaction, a amené le dispositif de transaction plus près du dispositif externe pour que les deux dispositifs soient couplés inductivement et puissent échanger des données. Lorsque la commande Select_PPSE est reçue, P2 passe à l'étape S35 au cours de laquelle il attend les données entrantes IAD envoyées par ED et reçues via Pl. Lorsque les données IAD sont reçues, P2 passe à l'étape S36 au cours de laquelle il traite les IAD et forme des données d'application sortantes OAD à l'attention de ED. Après l'étape S36, et selon la nature des données d'application en cours de traitement, soit P2 passe à une étape S37 au cours de laquelle il envoie la commande SEND_DATA [OAD] à P1 (qui traite cette commande lors des étapes S03, SO4 de la figure 6A), soit il passe à une étape S38 au cours de laquelle il envoie la commande SEND_PDOL à pl (qui traite cette commande lors des étapes S109, S110 de la figure 6A), puis retourne à l'étape d'attente S35. Il apparaîtra clairement à l'homme de l'art que de nombreux autres modes de réalisation du dispositif de transaction et du procédé de sécurisation d'une transaction selon l'invention peuvent être envisagés. A titre d'exemple, la figure 7 illustre un autre mode de réalisation d'un dispositif de transaction 3 selon l'invention, qui comprend les mêmes éléments que ceux décrits ci-dessus en relation avec la figure 2, c'est-à-dire le contrôleur de communication Pl et sa mémoire PMEM1, le processeur d'application P2 et sa mémoire PMEM2, le dispositif d'entrée ID et le dispositif d'affichage DD. Le dispositif de transaction se distingue du dispositif de transaction 2 en ce que le dispositif d'entrée ID est seulement connecté au contrôleur de communication Pl et est relié au processeur d'application P2 via le contrôleur Pl. Dans ce mode de réalisation du dispositif de transaction, une transaction est essentiellement traitée de la même manière que celle décrite plus haut en relation avec les figures 3A à 6B, sauf que le contrôleur de communication Pl est configuré pour transmettre au processeur d'application P2 tous types de données que l'utilisateur entre au moyen du dispositif d'entrée ID, pour qu'elles soient traitées par le processeur d'application P2, et pas seulement les données de transaction approuvées ATD. Étant donné que les architectures récentes de chipset NFC se basent sur un protocole HCI (Host Control Interface) selon lequel le contrôleur de communication Pl est configuré pour router les données entre les différents processeurs d'un chipset NFC, tel que proposé par la demande de brevet EP 1 855 389 au nom de la demanderesse, Pl peut aisément être configuré pour router jusqu'au processeur P2 les données émises par le dispositif d'entrée ID. Les données de transaction pouvant être protégées par la présente invention sont généralement un somme d'argent et la devise correspondante, mais peuvent également être, par exemple, un nombre � d'unités � ou de � jetons � ayant une valeur monétaire, une quantité de marchandises commandées lors de la transaction, et de façon générale toute donnée essentielle impliquée dans une transaction et devant faire l'objet de l'accord de l'utilisateur. Enfin, bien que les modes de réalisation de la présente invention aient été initialement conçus et développés pour les dispositifs portables comprenant un contrôleur de communication NFC, il apparaîtra clairement à l'homme de l'art que les procédés de transaction qui viennent d'être décrits sont applicables aux dispositifs de transaction utilisant différentes méthodes de communication avec des dispositifs externes et implémentant différentes normes de communication. 23 REVENDICATIONS1. Procédé de sécurisation d'une transaction entre un dispositif de transaction (2, 3) et un dispositif externe (ED), le dispositif de transaction comprenant un contrôleur de communication (Pl), un processeur d'application (P2), et un dispositif d'entrée (ID), la transaction comprenant l'échange de données d'application entre le dispositif de transaction et le dispositif externe, et une étape d'émission de données de transaction du dispositif de transaction vers le dispositif externe ou du dispositif externe vers le dispositif de transaction, caractérisé en ce qu'il comprend les étapes consistant à : - demander (S25, S25', S32) à l'utilisateur d'entrer 15 des données de transaction (ATD) approuvées via le dispositif d'entrée (ID), - surveiller (L04, L40) les données de transaction à envoyer au dispositif externe ou reçues du dispositif externe, et 20 - empêcher (S10) les données de transaction (TD) d'être envoyées au dispositif externe si elles sont différentes des données de transaction approuvées (ATD), ou rejeter (S113) les données de transaction reçues (TD) si elles sont différentes des données de transaction 25 approuvées (ATD). 2. Procédé selon la revendication 1, comprenant une étape consistant à interrompre la transaction au lieu d'empêcher les données de transaction d'être envoyées ou 30 de rejeter les données de transaction reçues. 3. Procédé selon l'une des revendications 1 et 2, comprenant les étapes consistant à : capturer et mémoriser (L03) les données de transaction approuvées (ATD) entrées par l'utilisateur, au moyen du contrôleur de communication, - surveiller (L04, L40) les données de transaction à envoyer au dispositif externe ou reçues du dispositif externe, au moyen du contrôleur de communication, et - configurer le contrôleur de communication de telle sorte qu'il refuse (S10) d'envoyer des données de transaction différentes des données de transaction approuvées (ATD), ou qu'il rejette (S113) les données de transaction reçues qui sont différentes des données de transaction approuvées (ATD). 4. Procédé selon l'une des revendications 1 à 3, comprenant une étape consistant à appliquer (S24, S31) au contrôleur de communication une commande (ATDR) lui demandant de capturer et mémoriser les données de transaction approuvées, avant de demander (S25, S25', S32) à l'utilisateur d'entrer des données de transaction approuvées (ATD). 5. Procédé selon l'une des revendications 1 à 4, comprenant les étapes consistant à : - appliquer (S27) une commande spécifique (SEND_TD) au contrôleur de communication lorsque des données de transaction doivent être envoyées au dispositif externe, et fournir au contrôleur de communication les données de transaction à envoyer (TD), - configurer le contrôleur de communication de telle sorte qu'en réponse à la commande il surveille les données de transaction spécifique, puis envoie les données de transaction au moyen d'une encapsulation spécifique ou de données d'accompagnement ({y[TD]y}, {x[TD]y}, {y[TD]x}) si les données de transaction (TD) à envoyer sont identiques aux données de transaction approuvées (ATD). 6. Procédé selon la revendication 5, comprenant une étape consistant à configurer le dispositif externe (ED) de telle sorte qu'il refuse les données de transaction qui ne sont pas encapsulées dans des données d'encapsulation spécifiques ({y[TD]y}, {x[TD]y}, {y[TD]x}) ou accompagnées de données d'accompagnement spécifiques 7. Procédé selon l'une des revendications 1 à 4, comprenant les étapes consistant à : - envoyer des données d'application au dispositif de 15 transaction au moyen d'une trame de données spécifique (Get Processing Options), - en réponse à la réception de la trame de données spécifique, comparer les données de transaction (TD) présentes dans la trame spécifique aux données de 20 transaction approuvées (ATD), au moyen du contrôleur de communication. 8. Dispositif de transaction (2, 3) comprenant un contrôleur de communication (Pl), un processeur 25 d'application (P2) pour réaliser des transactions avec un dispositif externe (ED) par l'intermédiaire du contrôleur de communication (Pl), et un dispositif d'entrée (ID), caractérisé en ce qu'il est configuré pour : - demander (S25, S25', S32) à l'utilisateur d'entrer 30 des données de transaction approuvées (ATD) via le dispositif d'entrée (ID) lors d'une transaction, - surveiller (L04, L40) les données de transaction (TD) à envoyer au dispositif externe ou reçues du dispositif externe, et - empêcher (S10) les données de transaction (TD) d'être envoyées au dispositif externe si elles sont différentes des données de transaction approuvées (ATD), ou rejeter (S113) les données de transaction reçues (TD) Si elles sont différentes des données de transaction approuvées (ATD). 9. Dispositif de transaction selon la revendication 8, caractérisé en ce qu'il est configuré pour interrompre une transaction (S10, S113) lorsque les données de transaction (TD) à envoyer sont différentes des données de transaction approuvées (ATD), ou lorsque les données de transaction reçues (TD) sont différentes des données de transaction approuvées (ATD). 10. Dispositif de transaction selon l'une des revendications 8 et 9, dans lequel le contrôleur de communication est configuré pour : - capturer et mémoriser (L03) les données de transaction approuvées (ATD) entrées par l'utilisateur, - surveiller (L04, L40) les données de transaction (TD) à envoyer au dispositif externe ou reçues du dispositif externe, et - refuser (S10) d'envoyer des données de transaction différentes des données de transaction approuvées (ATD), ou rejeter (S113) des données de transaction reçues différentes des données de transaction approuvées (ATD). 11. Dispositif de transaction selon l'une des revendications 8 à 10, dans lequel le processeur d'application est configuré pour demander (S25, S25', S32) à l'utilisateur d'entrer des données de transaction approuvées (ATD) et pour appliquer (S24, S31) au contrôleur de communication une commande (ATDR) lui demandant de capturer et de mémoriser les données detransaction approuvées, avant de demander à l'utilisateur d'entrer des données de transaction approuvées. 12. Dispositif de transaction selon l'une des 5 revendications 8 à 11, dans lequel : - le processeur d'application est configuré pour appliquer (S27) une commande spécifique (SENDTD) au contrôleur de communication lorsque des données de transaction doivent être envoyées au dispositif externe, 10 et fournir au contrôleur de communication les données de transaction à envoyer (TD), et - le contrôleur de communication est configuré pour surveiller les données de transaction en réponse à la commande spécifique, puis envoyer les données de 15 transaction (S11) au moyen d'une encapsulation spécifique ou de données d'accompagnement ({y[TD]y}, {x[TD]y}, {y[TD]x}) si les données de transaction (TD) à envoyer sont identiques aux données de transaction approuvées (ATD). 20 13. Dispositif de transaction selon l'une des revendications 8 à 11, dans lequel le contrôleur de communication est configuré pour, en réponse à la réception d'une trame de données spécifique 25 (Get Processing Options) comprenant des données de transaction (TD), comparer (S116) les données de transaction (TD) présentes dans la trame spécifique aux données de transaction approuvées (ATD). 30 14. Dispositif de transaction selon l'une des revendications 8 à 13, dans lequel le contrôleur de communication est un contrôleur NFC. 15. Dispositif de transaction selon l'une des 35 revendications 8 à 14, dans lequel le processeur d'application (P2) est un processeur de bande de base d'un téléphone portable ou le processeur principal d'un assistant numérique personnel. 16. Système de transaction, comprenant un dispositif de transaction selon l'une des revendications 8 à 15 et un dispositif externe (ED) configuré pour réaliser une transaction avec le dispositif de transaction (2, 3). 17. Système de transaction selon la revendication 16, dans lequel le dispositif externe est configuré pour refuser des données de transaction qui ne sont pas encapsulées dans des données d'encapsulation spécifiques ({y[TD]y}, {x[TD]y}, {y[TD]x}) ou accompagnées de données d'accompagnement spécifiques. 18. Système de transaction selon l'une des revendications 16 et 17, dans lequel le dispositif externe (ED) est configuré pour envoyer des données d'application au dispositif de transaction au moyen d'une trame de données spécifique (Get Processing Options).