FR3031609A1 - Procede de traitement d'une transaction a partir d'un terminal de communication - Google Patents

Abstract

Procédé de traitement, par un serveur de traitement de transactions, d'une transaction initiée au moins partiellement à partir d'un terminal de communication connectable audit serveur par l'intermédiaire d'un réseau de communication, procédé caractérisé en ce qu'il comprend : - une étape de création (10) d'un canal de communication sécurisé avec le terminal de communication ; - une étape d'instanciation (11), au sein d'un serveur d'exécution sur ledit réseau de communication, d'un terminal de paiement virtuel (VPOI) apte à échanger des informations avec ledit terminal de communication par le biais dudit canal de communication sécurisé ; - une étape de traitement (12) de transaction entre le terminal de communication et le terminal de paiement virtuel (VPOI) mettant en oeuvre au moins un module de sécurisation du terminal de communication, ledit module de sécurisation étant configuré pour échanger un identifiant du type de service et/ou un numéro d'identification personnel avec ledit terminal de paiement virtuel (VPOI).

Description

1 Procédé de traitement d'une transaction à partir d'un terminal de communication. 1. Domaine La technique proposée se rapporte au traitement de transactions en ligne. La technique proposée se rapporte plus particulièrement au traitement de transactions à partir d'un terminal de communication, sous une forme sécurisée. 2. Art Antérieur Deux modes de transactions coexistent lorsqu'un utilisateur souhaite effectuer une transaction de paiement à partir d'une carte bancaire : - le mode « carte présente » : la carte bancaire est physiquement utilisée. Elle est par exemple insérée dans un terminal de paiement, et les informations qu'elle contient sont lues directement à partir de la puce ou de la bande magnétique intégrées à la carte. Alternativement, la carte bancaire est approchée d'un terminal de paiement, et les informations sont transmises via une technologie sans contact de type NFC (de l'anglais « Near Field Communication ») ; le mode « carte non présente » : la carte bancaire n'est pas utilisée physiquement, mais l'utilisateur saisit les informations présentes sur cette carte (numéro de carte, cryptogramme visuel, date d'expiration, nom du porteur) pour effectuer une transaction. C'est la solution aujourd'hui majoritairement utilisée pour le paiement en ligne sur Internet par exemple. De nombreux fabricants de terminaux de communication mobiles (typiquement des smartphones ou des tablettes) cherchent aujourd'hui développer des solutions de paiement directement intégrées au terminal mobile, permettant à l'utilisateur de s'affranchir d'avoir à se munir de sa carte bancaire lorsqu'il souhaite effectuer une transaction. Les solutions proposées actuellement à cette fin reposent essentiellement sur une mise en oeuvre basée sur le mode de transaction de type « carte non présente » décrit précédemment : dans une première phase 3031609 2 d'initialisation du service, l'utilisateur est invité à saisir, au sein d'une application dédiée installée sur son terminal de communication, les informations associées à sa ou ses cartes bancaires (par exemple le type de carte, le numéro de carte, le cryptogramme visuel, la date d'expiration, etc.). Ces informations sont alors 5 enregistrées au sein même du terminal de communication. Cette phase d'initialisation terminée, l'utilisateur a alors la possibilité d'utiliser l'application dédiée pour effectuer certains paiements sans avoir à se munir de sa carte bancaire et devoir ressaisir manuellement les informations qui y sont indiquées : ces informations sont alors directement transmises par le terminal de 10 communication au serveur de paiement. Cette solution est néanmoins limitée. D'une part, les possibilités de transactions accessibles depuis un terminal de communication mobile limitées et ne concerne que les transactions en ligne reposant sur un mode « carte non présente », et la solution proposée vise alors essentiellement à éviter à 15 l'utilisateur d'avoir à saisir lui-même les données associées à sa carte bancaire à chaque fois qu'il souhaite effectuer un paiement depuis un terminal de communication (saisie souvent fastidieuse). D'autre part cette solution soulève des problèmes de sécurité : toutes les données utiles pour réaliser une transaction étant stockées au sein même du terminal de communication, un 20 utilisateur qui a égaré ou s'est fait subtiliser son dispositif mobile (son téléphone portable par exemple) n'est pas à l'abri qu'une personne malveillante qui a récupéré son bien accède à ces informations sensibles et réalise des transactions financières en son nom (si le terminal de communication ou l'application qui les contient sont insuffisamment sécurisés).

25 Ce problème de sécurisation qui se pose pour la réalisation de transactions de paiement à partir d'un terminal de communication est également rencontré dans la réalisation de transactions d'autres types : dès lors qu'une autorisation est requise pour la réalisation d'une transaction à partir d'un terminal de communication, il est risqué de stocker au sein de ce même terminal 30 de communication les informations susceptibles de donner accès à une telle 3031609 3 autorisation. Il existe donc un besoin d'une solution permettant d'intégrer au sein d'un terminal de communication des moyens d'obtention d'une autorisation pour la réalisation de transactions, et qui ne présente pas au moins certains de ces 5 problèmes de l'art antérieur. 3. Résumé Selon une implémentation préférée, les différentes étapes des procédés selon la technique proposée sont mises en oeuvre par un ou plusieurs logiciels ou programmes d'ordinateur, comprenant des instructions logicielles destinées à 10 être exécutées par un processeur de données d'un module relais selon la technique proposée et étant conçu pour commander l'exécution des différentes étapes des procédés. En conséquence, la technique proposée vise aussi un programme, susceptible d'être exécuté par un ordinateur ou par un processeur de données, 15 ce programme comportant des instructions pour commander l'exécution des étapes d'un procédé tel que mentionné ci-dessus. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou 20 dans n'importe quelle autre forme souhaitable. La technique proposée vise aussi un support d'informations lisible par un processeur de données, et comportant des instructions d'un programme tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif 25 capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur. D'autre part, le support d'informations peut être un support transmissible 30 tel qu'un signal électrique ou optique, qui peut être acheminé via un câble 3031609 4 électrique ou optique, par radio ou par d'autres moyens. Le programme selon la technique proposée peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré 5 dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Selon un mode de réalisation, la technique proposée est mise en oeuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant 10 logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels. Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en 15 oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci- dessous pour le module concerné. Un tel composant logiciel est exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, routeur, etc.) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, 20 cartes électroniques d'entrées/sorties, interfaces utilisateur, etc.). De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec 25 processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (firmware), etc. Chaque composante du système précédemment décrit met bien entendu en oeuvre ses propres modules logiciels.

3031609 5 Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en oeuvre de la technique proposée. 4. Figures D'autres caractéristiques et avantages de la technique proposée 5 apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : - la figure 1 présente un synoptique de la technique proposée ; 5. Description 10 Procédé La technique proposée ne présente pas au moins certains de ces problèmes de l'art antérieur. En effet, il est proposé ici un procédé de traitement d'une transaction effectuée à partir d'un terminal de communication. On entend ici le terme « transaction » au sens large : il peut s'agir aussi bien d'une 15 transaction financière (par exemple une transaction de paiement), que d'une transaction de tout autre nature, telle que la publication ou la suppression de commentaires sur un réseau social en ligne, ou tout autre transaction nécessitant l'obtention d'une autorisation pour être réalisée. Le principe général de la technique proposée consiste à s'appuyer sur les 20 mêmes mécanismes d'authentification que ceux mis en oeuvre dans le cadre de la réalisation d'une transaction de paiement à partir d'une carte bancaire dans un mode « carte présente », et à reprendre ces mécanismes dans le but d'obtenir une autorisation pour la réalisation d'une transaction quelconque (pas seulement des transactions de paiement) à partir d'un terminal de 25 communication. Un terminal de communication selon la technique proposée comprend un processeur sécurisé ayant accès à une mémoire sécurisée. Il est important de noter ici que ce processeur sécurisé et cette mémoire sécurisée sont dédiés à la réalisation de transactions, et qu'ils sont distincts du processeur central et de la 30 mémoire centrale qui régissent le fonctionnement courant du terminal de 3031609 6 communication (prise en charge d'appel, d'envoi de messages, navigation sur Internet, etc.). Ce processeur et cette mémoire sécurisés - qui forment donc un espace sécurisé au sein du terminal de communication - peuvent par exemple être intégrés au sein d'un environnement d'exécution sécurisé qui est livré au 5 fabricant de terminaux de communication. Cet environnement d'Exécution sécurisé (TEE) peut par ailleurs être complété d'un module de sécurisation (SE) dont la fonction dans la cadre de la présente technique est de dialoguer avec un terminal de paiement virtuel. Plusieurs types de service nécessitant l'obtention d'une autorisation pour la réalisation de transactions associées sont prédéfinis 10 au sein de ce module de sécurisation (par exemple sous la forme d'applications spécifiques, également appelées applets). Des exemples de tels types de service sont : paiement Visa®, paiement Mastercard®, service lié à un réseau social en ligne donné, etc. Chaque type de service prédéfini au sein d'un module de sécurisation est associé à un identifiant unique (PAN_S), construit sur le même 15 format qu'un numéro de carte bancaire (ou PAN, de l'anglais « Primary Account Number »). Chacun de ces identifiants est non seulement unique au sein d'un même module de sécurisation, mais il est également unique au sein de l'ensemble des modules de sécurisation commercialisés. Ainsi, un tel module de sécurisation fourni à un fabricant de terminaux de communication contient, pour 20 chaque type de service qui y est prédéfini, un identifiant qui fait office de signature unique et inaltérable et qui est construit sur le même format qu'un numéro de carte bancaire. Au sein de ce module de sécurisation, chaque type de service est stocké sous la même forme que le sont les données contenues dans une carte à mémoire de type carte bancaire (un type de service se comportant 25 alors vis-à-vis de l'extérieur, comme une carte bancaire virtuelle avec son propre numéro (PAN_S)). Lorsqu'un utilisateur prend possession d'un terminal de communication intégrant un tel module de sécurisation de transaction, il a la possibilité, dans une phase dite de provisionnement, d'activer certains de ces types de services, 30 pour lesquels il souhaite être en mesure d'effectuer une transaction associée au 3031609 7 moyen de son terminal de communication. Par exemple, si l'utilisateur souhaite pouvoir utiliser son téléphone pour réaliser des transactions de paiement, il va activer le type de service de paiement correspondant au type de carte en sa possession (par exemple « paiement VISA® » ou « paiement Mastercard® »). Si 5 l'utilisateur souhaite utiliser son téléphone pour bénéficier d'une sécurisation accrue lors de certaines opérations réalisées sur un réseau social, il va activer le type de service associé à ce réseau social. Dans la suite du document, on s'intéresse (mais ce choix est donné à titre purement illustratif et n'est pas limitatif) au type de service correspondant à un paiement VISA®.

10 Une fois le choix d'un type de service à activer effectué, la phase de provisionnement comprend une étape de fourniture des données associées au service particulier pour lequel une autorisation est requise lorsqu'une transaction est effectuée. Ainsi, si l'utilisateur souhaite pouvoir effectuer des paiements VISA® à partir de son terminal de communication, il doit fournir dans 15 cette phase de provisionnement les données associées à sa carte bancaire VISA® qui sont nécessaires à la réalisation d'une transaction : numéro de carte bancaire, date d'expiration, nom du porteur, cryptogramme visuel, etc. Cette étape peut être réalisée par le biais d'une saisie manuelle des informations présentes sur la carte bancaire, ou de manière automatique, par exemple au 20 moyen d'une photographie de la carte bancaire réalisée au moyen du terminal de communication (la quasi-totalité des terminaux de communication grand-public intègrent aujourd'hui des moyens pour prendre une photographie). Une donnée supplémentaire, dénommée « index » (IDX) est générée automatiquement par le terminal de communication, afin d'être en mesure de 25 distinguer différents jeux de données propres à un même type de service (un utilisateur qui disposerait de plusieurs cartes bancaires VISA® doit pouvoir provisionner chacune de ces cartes : l'identifiant unique du type de service (PAN _S) permet alors d'identifier non seulement un paiement VISA® mais également l'utilisateur qui le demande (cet identifiant étant unique au sein de 30 l'ensemble des modules de sécurisation), et l'index permet d'identifier le jeu de 3031609 8 données associé à la carte bancaire VISA® que l'utilisateur souhaite effectivement utiliser au moment d'un paiement à partir de son terminal de communication). Ces données sensibles associées à un service et fournies par l'utilisateur 5 ne sont pas stockées au sein du terminal de communication : elle sont transmises à un serveur de traitement des autorisations qui les stocke au sein d'une structure de données, dite structure de données de transactions (StrTrs), où elles sont associées à l'identifiant unique du type de service considéré (dans notre exemple considéré, le PAN_S du service « paiement VISA® » pour le terminal de 10 communication considéré), et à l'index généré automatiquement lors de leur fourniture. Les seules informations qui restent stockées au sein du terminal de communication (en plus des identifiants uniques PAN_S déjà prédéfinis au sein du module de sécurisation) sont l'index, ainsi qu'une représentation de la carte bancaire VISA® provisionnée (par exemple une photographie, une image, et/ou 15 les derniers chiffres de son numéro) qui sera utile ultérieurement pour permettre à l'utilisateur d'identifier plus facilement la carte qu'il souhaite utiliser (notamment si il a provisionné plusieurs cartes bancaires du même type). Le provisionnement d'un service par la saisie de données et la transmission de ces données à un serveur de traitement des autorisations est 20 mis en oeuvre sous le contrôle au moins partiel de l'environnement d'Exécution sécurisé (TEE) et/ou le module de sécurisation (SE). Les données sont transmises après l'établissement d'un canal sécurisé entre le terminal de communication et le serveur de traitement. Lorsque qu'une demande d'activation d'un type de service donné est 25 transmise à un serveur de traitement des autorisations, ce dernier génère puis transmet à l'utilisateur, via un canal de transmission sécurisé (par exemple directement par l'intermédiaire du canal sécurisé ou par un autre moyen comme la voie postale), un numéro d'identification personnel (PIN_S) (ou code PIN, de l'anglais « Personal Identification Number ») spécifiquement lié à l'identifiant 30 unique du type de service activé (PAN_S) (ce numéro d'identification personnel 3031609 9 n'est notamment pas celui qui est associé à la carte bancaire réelle de l'utilisateur). L'association entre l'identifiant unique du type de service activé (PAN S) et le numéro d'identification personnel correspondant (PIN_S) est _ _ stockée au sein d'une structure de données, dite structure de données 5 d'autorisation (StrAut), de ce serveur de traitement des autorisations. Alternativement, tous les types de service prédéfinis au sein d'un même module de sécurisation peuvent être associé au même numéro d'identification personnel (PIN_S). Ceci permet de définir un numéro d'identification personnel global associé au terminal de communication, et l'utilisateur n'a alors qu'un seul 10 numéro d'identification personnel à mémoriser (plutôt qu'un par type de service activé). Dans ce dernier cas, le numéro d'identification personnel associé au terminal de communication est par exemple généré puis transmis à l'utilisateur lors de sa toute première activation d'un type de service disponible. Ceci finalise la phase de provisionnement. On entre alors dans une phase 15 d'utilisation, et le procédé de traitement d'une transaction à partir d'un terminal de communication peut alors être mis en oeuvre. Selon la technique proposée, un tel procédé comprend, au niveau du serveur de traitement des autorisations, au moment où l'utilisateur souhaite effectuer une transaction nécessitant l'obtention d'une autorisation : 20 - une étape de création d'un canal de communication sécurisé (par exemple un réseau privé virtuel - VPN) avec le terminal de communication (TC) ; une étape d'instanciation d'un terminal de paiement virtuel (VPOI) apte à échanger des informations avec ledit terminal de communication par le 25 biais dudit canal de communication sécurisé, selon un même protocole de communication que celui utilisé pour les échange de données entre une carte bancaire physique et un terminal de paiement physique lors d'une transaction de paiement en mode « carte présente » (APDU : « Application Protocol Data Unit » encapsulées dans le protocole SCP) ; 30 - une étape d'obtention, au moyen dudit terminal de paiement virtuel 3031609 10 5 (VPOI), de l'identifiant du type de service (PAN_S) correspondant à la transaction à réaliser à partir dudit terminal de communication, et de l'index (IDX) correspondant au jeu de données à utiliser, ledit index étant contenu dans un champ disponible défini dans ledit protocole de communication (par exemple le champ « 9F10 », apte à accueillir des données propres à l'émetteur d'une carte) ; 10 une étape de transmission d'une demande de saisie d'un numéro d'identification personnel au terminal de communication ; 15 - une étape de réception d'un numéro d'identification personnel (PIN) saisi, sous une forme chiffrée; 20 une étape de vérification de l'adéquation entre le numéro d'identification personnel saisi (PIN) et le numéro d'identification personnel attendu (PIN S) pour le type de service considéré, au moyen de la structure de données d'autorisation (StrAut) ; lorsque ladite vérification est positive, une étape d'obtention des données (JD) nécessaires à la poursuite de la transaction, au moyen de la structure de données de transactions (StrTrs), en fonction de l'identifiant dudit type de service (PAN_S) correspondant à la transaction à réaliser à partir dudit terminal de communication, et dudit index (IDX) correspondant au jeu de données à utiliser ; Le protocole de communication établi entre le module de sécurisation présent dans le terminal de communication, pour un type de service donné, et le terminal virtuel instancié par le serveur de traitement des autorisations est donc similaire à celui mis en oeuvre lors des échanges entre une carte bancaire 25 physique et un terminal de paiement physique. Le processus d'obtention d'une d'autorisation pour la réalisation d'une transaction à partir d'un terminal de communication est alors similaire à celui qui est effectué lors d'une transaction de paiement en mode « carte présente » (le module de sécurisation du terminal de communication fait alors office de carte bancaire, et le terminal de paiement 30 virtuel se comporte comme un terminal de paiement classique). Au niveau du 3031609 11 terminal de communication, le procédé décrit est uniquement géré au niveau du module de sécurisation, afin de garantir une sécurisation maximale de la transaction. Ainsi, on se prémunit de l'action d'éventuels logiciels malveillants (par exemple des keyloggers) qui pourraient être installés sur le système 5 d'exploitation du terminal de communication. Les fonctionnalités classiques du terminal de communication (réception et émission d'appels, de messages, navigation internet, etc.) sont également désactivées tant que la transaction n'est pas terminée, et c'est le processeur sécurisé qui gère les périphériques de saisie et de restitution du terminal de communication (notamment l'affichage de 10 l'écran de demande de saisie du numéro d'identification personnel, ou code PIN, associé au type de service pour lequel la transaction est demandée ; et la récupération du code saisi par l'utilisateur). Dans un mode de réalisation particulier de la technique proposée, en cas de vérification négative de l'adéquation entre le numéro d'identification 15 personnel saisi et le numéro d'identification personnel attendu (PIN_S) pour le type de service considéré, on peut permettre à l'utilisateur d'effectuer un nombre prédéterminé de nouvelles tentatives de saisie d'un numéro d'identification personnel correct avant de rejeter définitivement la transaction, si de multiples saisies erronées sont répétées.

20 Dans un mode de réalisation particulier de la technique proposée, le numéro d'identification personnel saisi par l'utilisateur est crypté ou est transformé par une fonction de hachage au sein du terminal de communication ou du terminal de paiement virtuel, avant d'être transmis au serveur de traitement des autorisations. La vérification de l'adéquation entre le numéro 25 d'identification personnel saisi et le numéro d'identification personnel attendu (PIN_S) pour le type de service considéré est alors réalisé après décryptage du numéro d'identification personnel crypté reçu (cas du cryptage), ou sur la base d'une comparaison d'empreintes (cas du hachage). Dans l'exemple développé précédemment au long de ce document - la 30 réalisation d'une transaction de paiement à partir d'un terminal de 3031609 12 communication - il est intéressant de noter que la technique proposée permet la mise en oeuvre d'un mode de transaction hybride faisant intervenir à la fois une partie des mécanismes mis en oeuvre dans le cadre d'une transaction de paiement en mode « carte présente » et une partie de ceux mis en oeuvre dans le 5 cadre d'une transaction en mode « carte non présente » : - l'obtention de l'autorisation de réaliser une transaction est obtenue selon des mécanismes analogues à ceux mis en oeuvre lors de la réalisation d'une transaction en mode « carte présente » ; - néanmoins, une fois cette autorisation obtenue, les mêmes mécanismes 10 que ceux mis en oeuvre lors de la réalisation d'une transaction en mode « carte non présente » sont utilisés pour finaliser la transaction, à savoir la transmission des informations telles qu'inscrites sur une carte bancaire (numéro de carte, date d'expiration, cryptogramme visuel, nom du porteur) à un serveur de paiement. Ces informations sont récupérés dans la structure de données de 15 transactions (StrTrs) du serveur de traitement des autorisations, à partir de l'identifiant du type de service (PAN_S) pour lequel on souhaite effectuer une transaction, et de l'index (IDX) servant à identifier le jeu de données à utiliser pour finaliser cette transaction. Selon un autre aspect de la technique proposée, un terminal de 20 communication tel que celui décrit ici - qui inclut un module de sécurisation au sein duquel sont prédéfinis des types de service, et notamment des types de services de paiement correspond à des schémas de paiement de cartes bancaires, à même d'être provisionnés - peut être utilisé pour la réalisation d'une transaction de paiement sans contact en lien avec un terminal de 25 paiement physique (et non plus un terminal de paiement virtuel) (Dans ce cas, le terminal de communication et le terminal de paiement doivent comprendre des moyens de communication sans contact adaptés à ce type d'usage, par exemple des moyens de communication en champ proche (NFC). L'exemple développé majoritairement dans le présent document (la 30 réalisation d'une transaction de paiement) est donné à titre purement illustratif 3031609 13 et non limitatif. Il va de soi que le présent procédé de traitement d'une transaction peut être mise en oeuvre pour tout type de service (y compris des services sans rapport aucun avec le domaine financier) nécessitant l'obtention d'une autorisation pour la réalisation d'une transaction associée.

5 Dispositifs de mises en oeuvre On décrit, en relation avec la figure 2, un serveur de traitement comprenant des moyens permettant l'exécution du procédé décrit préalablement. Par exemple, le serveur de traitement comprend une mémoire 41 10 constituée d'une mémoire tampon, une unité de traitement 42, équipée par exemple d'un microprocesseur, et pilotée par le programme d'ordinateur 43, mettant en oeuvre les étapes nécessaires au traitement d'autorisation de mise en oeuvre de services ou d'accès à des biens. À l'initialisation, les instructions de code du programme d'ordinateur 43 15 sont par exemple chargées dans une mémoire avant d'être exécutées par le processeur de l'unité de traitement 42. L'unité de traitement 42 reçoit en entrée par exemple un ensemble de lexèmes initiaux ou des données de dictionnaires existant. Le microprocesseur de l'unité de traitement 42 met en oeuvre les étapes du procédé, selon les instructions du programme d'ordinateur 43 pour 20 permettre l'accès au bien ou au service. Pour cela, le serveur de traitement comprend, outre la mémoire tampon 41, des moyens d'obtention d'une information externe au dispositif, comme un ensemble de données accessibles en base ; ces moyens peuvent se présenter sous la forme d'un module d'accès à un réseau de communication tel qu'une 25 carte réseau. Le dispositif comprend également des moyens de traitement, de ces données pour délivrer des données permettant l'accès à un terminal de communication; ces moyens de traitement comprennent par exemple un processeur spécialisé dans cette tâche ; le dispositif comprend également un ou plusieurs moyens d'accès à une ou plusieurs bases de données. Le dispositif 30 comprend également des moyens de mises à jour d'autorisation et/ou d'accès à 3031609 14 des biens ou des services, notamment des moyens de pondération de relations entre les formes lexicales et/ou grammaticales composant le dictionnaire. Ces moyens peuvent être pilotés par le processeur de l'unité de traitement 42 en fonction du programme d'ordinateur 43.

5 On décrit, en relation avec la figure 3, un terminal de communication comprenant des moyens permettant l'exécution du procédé décrit préalablement. Par exemple, le terminal de communication comprend une mémoire 51 constituée d'une mémoire tampon, une unité de traitement 52, équipée par 10 exemple d'un microprocesseur, et pilotée par le programme d'ordinateur 53, mettant en oeuvre nécessaires à la mise en oeuvre des fonctions de vérification. À l'initialisation, les instructions de code du programme d'ordinateur 53 sont par exemple chargées dans une mémoire avant d'être exécutées par le processeur de l'unité de traitement 52. L'unité de traitement 52 reçoit en entrée 15 par exemple une notification. Le microprocesseur de l'unité de traitement 52 met en oeuvre les étapes du procédé de traitement, selon les instructions du programme d'ordinateur 53 pour permettre la saisie d'un code d'autorisation (un code PIN par exemple). Pour cela, le dispositif comprend, outre la mémoire tampon 51, des 20 moyens d'affichage et de saisie ; ces moyens peuvent se présenter sous la forme d'un processeur ou d'un ensemble de ressources sécurisées permettant de sécuriser la saisie de l'autorisation. Le dispositif comprend également des moyens de traitement cryptographiques ; ces moyens de traitement comprennent par exemple un processeur de chiffrement dédié et des clés de 25 chiffrement, comme des clés de session dérivée d'une clé initiale. Ces moyens peuvent être pilotés par le processeur de l'unité de traitement 52 en fonction du programme d'ordinateur 53. 30

Claims (2)

1. REVENDICATIONS1. Procédé de traitement, par un serveur de traitement de transactions, d'une transaction initiée au moins partiellement à partir d'un terminal de communication connectable audit serveur par l'intermédiaire d'un réseau de communication, procédé caractérisé en ce qu'il comprend : une étape de création (10) d'un canal de communication sécurisé avec le terminal de communication ; une étape d'instanciation (11), au sein d'un serveur d'exécution sur ledit réseau de communication, d'un terminal de paiement virtuel (VPOI) apte à échanger des informations avec ledit terminal de communication par le biais dudit canal de communication sécurisé ; une étape de traitement (12) de transaction entre le terminal de communication et le terminal de paiement virtuel (VP01) mettant en oeuvre au moins un module de sécurisation du terminal de communication, ledit module de sécurisation étant configuré pour échanger un identifiant du type de service et/ou un numéro d'identification personnel avec ledit terminal de paiement virtuel (VPOI).
2. 2. Procédé de traitement selon la revendication 1, caractérisé en ce que ladite étape de traitement de transaction comprend au moins un échange de données sous la forme d'un APDU entre le module de sécurisation et le terminal de paiement virtuel.