FR 3116920 A1 20220603 FR 2012428 A 20201130 Il est divulgué un procédé de traitement de données issue d’une saisie sur un écran tactile d’un terminal électronique (TermEt) comprenant des moyens de connexion à serveur transactionnel intermédiaire (Sti), procédé qui comprend : la réception (A01) d’un aléa (Dra, ParT), en provenance du serveur transactionnel intermédiaire ( Sti ) par l’intermédiaire l’une liaison sécurisée ; la réception (A02), en provenance d’un contrôleur (CtrlDT) de dalle tactile, de coordonnées ( x,y ) d’appui sur la dalle tactile ; la transformation (A03), par l’intermédiaire d’une fonction de transformation f Ts , des coordonnées ( x,y ) d’appui sur la dalle tactile, à l’aide de la dite au moins une donnée représentative d’un aléa (Dra, ParT), délivrant une donnée de caractère aléatoire (DrCa) ; la transmission (A04), de la donnée représentative d’un caractère aléatoire (DrCa) à un terminal de vérification. Figure 1 DESCRPTION TITRE : Procédé de traitement d’une opération impliquant des données secrètes, terminal, système et programme d’ordinateur correspondant Domaine technique La divulgation se rapporte au domaine de la sécurité informatique. Plus particulièrement, la divulgation se rapporte à la sécurité et à la confidentialité du traitement de données au sein d’un terminal de communication, tel qu’un smartphone ou un terminal traitant des données sensibles muni d’un écran tactile. Technique antérieure Depuis l’adoption massive de terminaux de communication intelligents (smartphone) par une grande partie de la population, l’idée est née de pouvoir réaliser un paiement par l’intermédiaire d’un tel terminal. L’apparition, plus récente, sur ces terminaux, de moyens de communication sans contact (interface de communication de type NFC) a permis d’envisager sérieusement la mise en œuvre de transactions de paiement directement sur ces terminaux. Le principe général qui a été initialement envisagé consistait à utiliser une carte de paiement sans contact que l’utilisateur appose sur son terminal de communication. Une application spécifique, installée sur le terminal de communication et sécurisée est supposée obtenir les données nécessaires de la carte bancaire de l’utilisateur et utiliser ces données pour effectuer la transaction de paiement. Rapidement, le besoin de sécuriser une telle transaction est apparu, notamment pour faire en sorte que la transaction générée soit considérée comme une transaction « carte présente », gage d’une plus grande sécurité de la transaction de paiement. Or, pour délivrer une transaction « carte présente », il est nécessaire que la carte bancaire de l’utilisateur joue un rôle « actif » dans la transaction, ce rôle ne se bornant pas à une simple fourniture, sans contact, des données de paiement (numéro, nom, date, code de validation). Ainsi, le besoin de saisir un code PIN (« Personnal Idnetificaiton Number ») sur l’écran tactile du terminal de communication est apparu. L’utilisation de ce code PIN saisi par l’utilisateur pour la mise en œuvre de la transaction est similaire à l’utilisation de ce même code PIN sur un terminal de paiement « classique » (i.e. avec une carte à puce). Les industriels ont donc débuté des travaux pour pouvoir mettre en œuvre de telles saisies de code PIN sur écran tactile. Rapidement, en parallèle, il est apparu qu’il était n’était pas forcément nécessaire d’utiliser une carte de paiement physiquement apposée sur le terminal pour mener des transactions. Le principe de « Card On File » est ainsi apparu, notamment pour les terminaux de communications haut de gamme, qui disposaient de fonction de sécurité plus évoluée (présence notamment d’un environnement d’exécution sécurisé -TEE – « Trusted Execution Environment » ) pour pouvoir transmettre des données de paiement. On note par ailleurs que ces données de paiement peuvent théoriquement être transmises en ligne (i.e. via l’utilisation d’une application marchande sur le terminal de communication de l’utilisateur) et en sans contact (en apposant le terminal de communication de l’utilisateur sur le terminal de paiement physique d’un marchand). Quoi qu’il en soit, et malgré les avancées en termes de sécurité pour le traitement de ces données bancaire par le terminal de communication (à écran tactile), le besoin de pouvoir effectuer une saisie d’un code PIN relatif à des données bancaires persiste, car il est un gage de sécurité supplémentaire. Ce besoin de saisie de code PIN a par ailleurs évolué avec le temps, en passant d’un besoin plutôt lié à une saisie sur un terminal de communication d’un utilisateur, à un besoin lié à la saisi d’un code PIN sur écran tactile sur de nombreux types de terminaux, qu’il serait pratique de pouvoir utiliser en toute sécurité pour pouvoir effectuer la saisie du code PIN. Dans la cadre de la présente, on s’intéresse par exemple à la saisie d’une information secrète sur un terminal à écran tactile (de type terminal de communication), dans le cadre d‘une transaction de paiement menée avec un terminal de paiement (qu’il s’agisse d’un terminal physique, chez un commerçant, ou d’un terminal distant, par exemple installé sur un serveur de traitement implémentant un terminal de paiement). Dans cette configuration, l’utilisateur du terminal de communication utilise donc ce terminal pour saisir l’information secrète, celle-ci étant ensuite transmise au terminal de paiement (physique ou distant), qui valide la conformité de l’information secrète. En d’autres termes, on scinde, dans deux dispositifs différents (dont un terminal à écran tactile, non nécessairement sécurisé et un terminal de vérification « sécurisé »), une opération (la saisie de l’information secrète) qui jusqu’alors était réalisée sur un seul et même dispositif : uniquement un terminal sécurisé. Ces considérations contextuelles étant exposées, de manière concrète, la saisie des touches du code PIN est réalisée sur un clavier virtuel de l’écran tactile. Le clavier virtuel se présente sous la forme d’un clavier affiché par une application (sécurisée) qui s’exécute sur le terminal à écran tactile. Une première méthode envisagée par les inventeurs a consisté en la transformation des évènements d’appui touche (« touch event ») du clavier virtuel en caractères (numériques) directement sur l’application du terminal à écran tactile, en passant par un principe d’obfuscation. Malgré ces mesures de protection, cette méthode n’a pas résisté à l’inspection par le laboratoire en charge de l’évaluation sécuritaire de l’application. L’une des caractéristiques du problème auquel les inventeurs doivent faire face est que l’application en charge de gestion de la saisie du code PIN s’exécute sur un terminal « ouvert ». Le terminal « ouvert » est qualifié de la sorte car il est géré par un utilisateur, qui peut y installer des applications logicielles de son choix. Cette possibilité est offerte par l’éditeur du dispositif d’exploitation du terminal ouvert (comme par exemple Android™ ou iOS™). Dans la mesure où il est admis que ces applications librement installables ne sont pas sécurisées (c’est-à-dire qu’elles peuvent comprendre toute ou partie des modules frauduleux) ou que l’utilisateur peut lui-même mettre en danger la sécurité du terminal ouvert en ayant des comportement non adaptés, le terminal ouvert est par nature considéré comme non sécurisé, et donc comme présentant potentiellement des risques pour le fonctionnement d’une application qui gère des données confidentielles, comme des données de paiement. Ainsi, lors de l’évaluation de la sécurité d’une telle application, l’évaluateur a à sa disposition la maitrise de l’intégralité du terminal à écran tactile sur lequel l’application qui gère la saisie du code PIN est installée. Une première méthode de résolution du problème de maitrise posé par l’évaluateur consisterait à disposer, au sien du terminal de vérification « securisé », d’une table de transformation des évènements d’appui touche (« touch events ») en caractères. L’inconvénient de cette méthode est qu’elle repose sur un secret qui est embarqué dans l’application du terminal de vérification, et donc également attaquable par un fraudeur (ou un évaluateur), bien qu’une telle opération soit plus complexe. Ainsi, malgré la possibilité théorique d’utiliser un terminal à écran tactile pour mettre en œuvre une saisie d’un information secrète, de manière sécurisée, cette possibilité se révèle, en pratique, non implémentable. Résumé de l'invention La divulgation permet de répondre en partie au moins aux problématiques posées par l’art antérieur. Plus particulièrement, la divulgation se rapporte à un procédé de traitement de données issue d’une saisie sur un écran tactile, procédé mis en œuvre au sein d’un terminal électronique comprenant un écran tactile sur lequel les données sont saisies, ledit terminal électronique comprenant des moyens de connexion à serveur transactionnel intermédiaire. Un tel procédé comprend : une étape de réception, en provenance du serveur transactionnel intermédiaire auquel le terminal à écran tactile est connecté par l’intermédiaire l’une liaison sécurisée, d’au moins une donnée représentative d’un aléa ; une étape de réception, en provenance d’un contrôleur de dalle tactile, de données représentatives de coordonnées ( x,y ) d’appui sur la dalle tactile du terminal ; une étape de transformation, par l’intermédiaire d’une fonction de transformation f Ts , desdites données représentatives de coordonnées ( x,y ) d’appui sur la dalle tactile du terminal, à l’aide de la dite au moins une donnée représentative d’un aléa, délivrant une donnée représentative d’un caractère aléatoire ; une étape de transmission, de la donnée représentative d’un caractère aléatoire à un terminal de vérification. Ainsi, la divulgation offre la possibilité de gérer de manière sécurisée, la saisie de données confidentielles sur un terminal de saisie qui peut être compromis, car les données de conversions de caractères ne sont pas à la disposition du terminal électronique, qui ne possède qu’un ou plusieurs aléas. Le terminal à écran tactile n’a donc pas à sa disposition d’information permettant de retrouver le code confidentiel que l’utilisateur a souhaité saisir. Selon une caractéristique particulière, l’étape de transformation comprend l’application de la fonction de transformation suivante : C sa est un caractère aléatoire obtenu, qui est transmis sous la forme de la donnée représentative d’un caractère aléatoire; R est une résolution de l’écran ; x est l’abscisse des données représentatives de coordonnées ( x,y ) ; y est l’ordonnée des données représentatives de coordonnées ( x,y ) ; a est un aléa inséré dans la calcul, aléa obtenu à partir de ladite moins une donnée représentative d’un aléa ; Ainsi, il n’est pas possible, même en connaissance de la fonction, de déterminer quel le résultat de celle-ci, puisque ce résultat dépend d’un aléa transmis, en ligne, voire en temps réel, par le serveur transactionnel intermédiaire. Selon une caractéristique particulière, la fonction de transformation met en œuvre une permutation aléatoire, générée par le serveur transactionnel intermédiaire et reçue au moins en partie par le terminal électronique. Selon une caractéristique particulière, la fonction de transformation met en œuvre une fonction de module, dont les paramètres ont aléatoirement été déterminés par le serveur transactionnel intermédiaire et reçue au moins en partie par le terminal électronique. Selon une caractéristique particulière, le procédé de traitement comprend en outre, préalablement à l’étape de réception, de ladite au moins une donnée représentative d’un aléa, une étape optionnelle de transmission, au serveur transactionnel intermédiaire, de données représentatives d’une résolution d’écran de l’écran tactile du terminal électronique. Selon une caractéristique particulière, le procédé de traitement est mis en œuvre lors de l’exécution d’une transaction électronique de paiement impliquant la saisie, par un utilisateur, d’un code d’identification personnel sur l’écran tactile du terminal électronique. Selon un autre aspect, l’invention se rapporte également à un terminal électronique comprenant un écran tactile sur lequel des données sont saisies, ledit terminal électronique comprenant des moyens de connexion à serveur transactionnel intermédiaire. Un tel terminal comprend : des moyens de réception, en provenance du serveur transactionnel intermédiaire auquel le terminal à écran tactile est connecté par l’intermédiaire l’une liaison sécurisée, d’au moins une donnée représentative d’un aléa ; des moyens de réception, en provenance d’un contrôleur de dalle tactile, de données représentatives de coordonnées ( x,y ) d’appui sur la dalle tactile du terminal ; des moyens de transformation, par l’intermédiaire d’une fonction de transformation f Ts , desdites données représentatives de coordonnées ( x,y ) d’appui sur la dalle tactile du terminal, à l’aide de la dite au moins une donnée représentative d’un aléa, délivrant une donnée représentative d’un caractère aléatoire ; des moyens de transmission, de la donnée représentative d’un caractère aléatoire au serveur transactionnel intermédiaire. Selon un autre aspect, la divulgation se rapporte également à un serveur transactionnel intermédiaire, serveur du type comprenant une unité centrale, une mémoire et des moyens de réception et de transmission de données en provenance d’un réseau de communication. Un tel serveur comprend : des moyens de détermination de données représentatives d’une résolution d’un écran tactile d’un Terminal électronique sur lequel une donnée doit être saisie ; des moyens de génération d’au moins une donnée représentative d’un aléa, optionnellement en fonction des données représentatives d’une résolution d’écran de l’écran tactile du terminal électronique ; des moyens de transmission de ladite au moins une donnée représentative d’un aléa au terminal électronique , et des moyens de transmission, à un terminal de vérification, d’une table de décodage de caractères saisis sur ledit écran tactile du Terminal électronique. Selon un autre aspect, la divulgation se rapporte également à un terminal de vérification de validité de données saisies sur un écran tactile d’un terminal à écran tactile, terminal du type comprenant une unité centrale, une mémoire et des moyens de réception et de transmission de données en provenance d’un réseau de communication. Un tel terminal comprend : des moyens de de réception, en provenance d’un serveur transactionnel intermédiaire, d’une table de décodage de caractères saisis sur ledit écran tactile du Terminal électronique ; des moyens des moyens de réception, en provenance du terminal électronique comprenant un écran tactile, de données représentatives d’un caractère aléatoire obtenues par l’exécution d’une fonction de transformation f Ts , de données représentatives de coordonnées (x,y) d’appui sur la dalle tactile du terminal, à d’au moins une donnée représentative d’un aléa ; des moyens de conversion des données représentatives des caractères aléatoires en caractères effectivement saisis ; des moyens de validation des caractères effectivement saisis pour une validation d’une transaction. Selon un autre aspect, la divulgation se rapporte également à un système de traitement de données issue d’une saisie sur un écran tactile, système comprenant un terminal électronique, un serveur transactionnel intermédiaire et un terminal de vérification selon la revendication tels que décrits précédemment. Selon une implémentation préférée, les différentes étapes des procédés selon la présente divulgation sont mises en œuvre par un ou plusieurs logiciels ou programmes d'ordinateur, comprenant des instructions logicielles destinées à être exécutées par un processeur de données d'un terminal d’exécution selon la présente technique et étant conçu pour commander l'exécution des différentes étapes des procédés, mis en œuvre au niveau du terminal de communication, du terminal électronique d’exécution et/ou du serveur distant, dans le cadre d’une répartition des traitements à effectuer et déterminés par un code source scripté ou un code compilé. En conséquence, la présente technique vise aussi des programmes, susceptibles d’être exécutés par un ordinateur ou par un processeur de données, ces programmes comportant des instructions pour commander l'exécution des étapes des procédés tel que mentionnés ci-dessus. Un programme peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. La présente technique 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 terminal 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 un support mobile (carte mémoire) ou un disque dur ou un SSD. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon la présente technique 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é 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 présente technique est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant 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 œuvre 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, set-top-box, routeur, etc. ) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, 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 œuvre 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 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 œuvre ses propres modules logiciels. Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en œuvre de la présente technique. Brève description des dessins D’autres caractéristiques et avantages 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 : [Fig. 1] expose le principe général du procédé de traitement de données saisies sur un écran tactile selon la présente technique ; [Fig. 2] expose un procédé de traitement de transaction de paiement dans lequel le procédé de la figure 1 est mis en œuvre ; [Fig. 3] est une représentation schématique d’un terminal à écran tactile pour la mise en œuvre du procédé de traitement de données précédemment présenté ; [Fig. 4] est une représentation schématique d’un serveur transactionnel intermédiaire pour la mise en œuvre du procédé de traitement de données précédemment présenté. Description détaillée Le principe général de la présente technique repose sur la mise en œuvre d’une fonction secrète, cette fonction n’étant pas en possession du terminal de communication qui est utilisé pour effectuer la saisie du code d’identification personnel. Plus particulièrement, le clavier virtuel est affiché sur le terminal de communication. Ce clavier virtuel affiche les chiffres et/ou caractères à utiliser pour saisir l’information secrète détenue par l’utilisateur (code d’identification personnel, mot de passe, etc.). Le clavier virtuel affiché peut être un clavier standard, adapté en fonction de la langue et du pays de l’utilisateur (le clavier est alors immédiatement reconnu par l’utilisateur). Cependant, selon la présente technique, le clavier virtuel est un clavier spécifiquement dédié à la saisie des données requises par le traitement sécurisé à mettre en œuvre. Auquel cas, le clavier est généré par l’application requérant la saisie sécurisée. Le clavier peut être affiché aléatoirement. En d’autres termes, les touches du clavier ne sont pas nécessairement affichées selon l’ordre standard. Les touches peuvent être mélangées de sorte à produire un affichage aléatoire de ces touches sur l’écran tactile de saisie. Ceci rend la saisie plus compliquée pour l’utilisateur, mais évite qu’un programme frauduleux ou malveillant infère des touches sur la base d’autres évènements que les évènements de saisie. Quel que soit l’affichage réalisé, le programme informatique en charge requiert la saisie les informations de l’utilisateur. Selon la présente technique, pour empêcher que les informations saisies ne soient interceptées par un programme malveillant, une fonction secrète est mise en œuvre au sein du programme légitime, pour délivrer un caractère aléatoire résultant de la saisie effectuée par l’utilisateur. Dans une version non sécurisée, telle que présentée précédemment, le programme de saisie de données sur l’écran tactile transforme un appui sur l’écran tactile en coordonnées {x ;y}, le point de référence de l’écran étant traditionnellement le coin supérieur gauche (qui représente les coordonnées {0 ;0}). Une fonction de transformation f Tns est alors utilisée, au sein du programme, pour transformer ces coordonnées {x ;y} en un caractère saisit. Notamment, la fonction de transformation f Tns prend en compte la résolution de l’écran tactile du terminal et transforme la saisie effectuée : [Math 2] (1) Dans laquelle C s est le caractère saisit (reconnu) ; R est la résolution de l’écran ; x est l’abscisse ; y est l’ordonnée. Dans cette version de base, implantée massivement sur les terminaux de saisie à l’heure actuelle, la fonction f Tns effectue une transformation {x ;y} en un indice pour connaître l'emplacement de l'appui sur le clavier virtuel. Une telle fonction est par exemple implémentée par les claviers de Google™ Gboard™ ou encore d’Apple™. Comme explicité précédemment, ce type de fonction non sécurisée n’est pas réellement utilisable pour la saisie d’informations sensibles. Les inventeurs ont donc eu l’idée de proposer une nouvelle fonction pour qu’elle intègre un nouveau paramètre : il s’agit d‘un paramètre aléatoire ( a ). Cet aléa ( a ) est introduit à chaque appui de touche et permet de modifier le résultat du calcul de la fonction. La nouvelle fonction f Ts est donc : [Math 3] (2) C sa est le caractère aléatoire obtenu ; R est la résolution de l’écran ; x est l’abscisse ; y est l’ordonnée ; a est l’aléa inséré dans la calcul. Selon la présente technique, l’aléa n’est pas déterminé par le terminal à écran tactile. En effet, on tente de se prémunir d’un programme frauduleux qui serait installé sur ce terminal. On part donc du principe que ce terminal à écran tactile est corrompu et donc du principe que ses ressources sont potentiellement sous contrôle de ce programme frauduleux (ressources dont le générateur aléatoire ou pseudo aléatoire du terminal peut faire partie). Cet aléa n’est pas non plus déterminé par le terminal de vérification « sécurisé » auquel l’information saisie est transmise pour validation de conformité, car ce terminal pourrait potentiellement être lui-même sous le contrôle d’une application frauduleuse. En conséquence, afin de se prémunir de ce type de menace, l’aléa (a) est reçu en provenance d’un serveur auquel le terminal à écran tactile est connecté. Plus particulièrement, l’aléa est reçu en provenance d’un serveur qui peut être en charge de la mise en œuvre conjointe de la transaction avec le terminal à écran tactile et/ou le terminal de vérification. Ce serveur est appelé serveur transactionnel intermédiaire. Ainsi, la technique décrite s’inscrit partiellement dans la mise en œuvre d’un système comprenant un serveur transactionnel intermédiaire, un terminal de vérification « sécurisé » (pouvant prendre la forme d’un terminal physique ou d’un terminal distant (i.e. virtuel ») et le terminal à écran tactile en possession de l’utilisateur, terminal qui est en charge de l’obtention de données personnelles et confidentielles détenues par l’utilisateur (i.e. code d’identification personnel, mot de passe). On note que ces données ne sont pas « sauvegardées » sur le terminal à écran tactile. Par essence, ces données sont destinées à mettre en œuvre une transaction requérant une identification ou une authentification : elles ne sont donc pas en possession du terminal à écran tactile de l’utilisateur et il n’est pas envisagé que ces données soient enregistrées par le terminal pour faciliter l’usage de celui-ci (il ne s’agit pas par exemple de laisser le terminal à écran tactile prendre la main pour sauvegarder ces données de manière sécurisée au sein du terminal). On rappelle en effet qu’on estime que le terminal est corrompu, il est donc préférable d’éviter d’y enregistrer ce type de données. Le fonctionnement de la présente technique consiste à insérer un aléa dans la fonction de calcul des caractères qui sont saisis sur le clavier affiché sur le terminal à écran tactile. Pour ce faire, l’aléa est déterminé par un serveur transactionnel intermédiaire, et un aléa différent est potentiellement utilisé pour chaque appui de touche sur l’écran tactile. Le serveur transactionnel intermédiaire peut transmettre les aléas sous la forme d’une liste d’aléa [a 1 , a 2 , a 3 , a 4 , a 5 ,… a n ] , lors de l’initialisation de la transaction avec le terminal à écran tactile. Le serveur intermédiaire peut également transmettre un aléa après chaque appui touche, selon un procédé dans lequel le premier aléa est transmis par le serveur intermédiaire ; puis l’utilisateur appuie sur l’écran tactile ; le terminal détermine un caractère à l’aide de la fonction f Ts ; le terminal transmet le résultat obtenu par la fonction f Ts au terminal de vérification ; à réception de ce résultat, dont il est informé par le terminal de vérification ou directement par le terminal à écran tactile, le serveur intermédiaire génère un nouvel aléa et la transmet au terminal à écran tactile, etc. Quel que soit la manière dont les aléas sont transmis au terminal à écran tactile, selon la présente technique, le caractère de validation, qui est utilisé pour signifier la fin de la saisie par l‘utilisateur (il s’agit généralement du caractère « entrée » (« return ») ou encore d’une touche « OK »), n’est pas traité différemment des autres caractères du clavier. Un aléa est également utilisé pour ce caractère ou cette fonction de validation . Cette caractéristique est importante car elle permet d’assurer qu’une application malveillante installée sur le terminal à écran tactile ne peut pas deviner ou inférer quand la saisie du mot de passe est terminée, même si cette application malveillante réussit à intercepter les caractères générés par la fonction f Ts . Ainsi, l’application malveillante ne peut pas deviner par exemple la longueur du mot de passe. Selon la présente technique, l’affichage du clavier sur le terminal à écran tactile est géré au moins partiellement par le serveur intermédiaire. C’est le serveur intermédiaire (ou le terminal de vérification) qui instruit le programme informatique de saisie du mot de passe sur le terminal à écran tactile de fermer le clavier de saisie du mot de passe ou du code d’identification personnel. Pour ce faire, le programme informatique de saisie, reçoit, en provenance du serveur intermédiaire (ou du terminal de vérification), une instruction de fermeture encapsulée dans un message. Cela permet de limiter voire de supprimer les risques de prise de contrôle du programme informatique de saisie par une application malveillante. Concrètement, l’application de gestion de transaction, lors de son démarrage, transmet au serveur intermédiaire, la résolution de l’écran sur laquelle elle s’exécute (ou toute autre information permettant au serveur de déterminer cette résolution, comme par exemple un identifiant du terminal à écran tactile, identifiant qui permet au serveur intermédiaire de retrouver la résolution de l’écran tactile du terminal). En fonction de cette résolution, le serveur détermine une correspondance aléatoire entre les évènements de touche ( x,y ) et le caractère correspondant. La explicite les différentes étapes du procédé de traitement selon la présente technique. Un tel procédé de traitement comprend : une étape optionnelle de transmission (A00), à un serveur transactionnel, de données (DRT) représentatives d’une résolution d’écran de l’écran tactile du terminal à écran tactile ; ces données représentatives peuvent effectivement être une résolution d’écran, un identifiant de terminal permettant d’obtenir une telle résolution, à partir de données disponibles auprès du serveur transactionnel, ou encore un identifiant d’application permettant d’obtenir des telles données ;cette étape n’a pas de caractère obligatoire, car en fonction de modes de réalisation, il n’est pas nécessaire de disposer d’une telle résolution pour mettre en œuvre la technique décrite ; une étape de réception (A01), en provenance du serveur transactionnel intermédiaire ( Sti ) auquel le terminal à écran tactile (TermEt) est connecté par l’intermédiaire d’une liaison sécurisée, d’au moins une donnée représentative d’un aléa (Dra, ParT), optionnellement en fonction des données (DRT) représentatives d’une résolution d’écran de l’écran tactile du terminal à écran tactile ; une étape de réception (A02), en provenance d’un contrôleur (CtrlDT) de dalle tactile, de données représentatives de coordonnées ( x,y ) d’appui sur la dalle tactile du terminal ; il s’agit par exemple d’un appui effectué avec un doigt en provenance d’un utilisateur saisissant un mot de passe ou un code d’identification personnel ; une étape de transformation (A03), par l’intermédiaire de la fonction de transformation f Ts , desdites données représentatives de coordonnées ( x,y ) d’appui sur la dalle tactile du terminal, à l’aide de la dite au moins une donnée représentative d’un aléa (Dra, ParT), délivrant une donnée représentative d’un caractère aléatoire (DrCa) ; une étape de transmission (A04), de la donnée représentative d’un caractère aléatoire (DrCa) au terminal de vérification. Dans un exemple de réalisation, l’implémentation de l’aléa est mise en œuvre par une permutation aléatoire. Une permutation aléatoire est tirée, par le serveur intermédiaire, et chaque caractère est choisi comme un élément de cette permutation choisie. Le serveur intermédiaire transforme cette fonction en table et la transmet au terminal de vérification, par exemple à l’initialisation de la transaction (c’est-à-dire après l’établissement de la liaison sécurisée avec le serveur intermédiaire). Le serveur intermédiaire transmet ensuite à l'application "l'aléa" (a) qui permet de sélectionner la permutation dans la table de permutation. Une table de permutation différente peut être transmise pour chaque caractère saisi. Deux variantes distinctes peuvent être mises en œuvre dans la cas de cette permutation aléatoire : la première variante consiste à effectuer une permutation aléatoire de caractères, directement à partir des caractères du clavier, par exemple un clavier « qwerty » aura une permutation « rteywq » (exemple volontairement limité) ou un clavier « 1234567890 » aura une permutation « 8463917205 » ; la deuxième variante consiste à effectuer une permutation aléatoire des appuis touches (coordonnées x,y) ; ce qui est plus efficace en termes de sécurité, mais également plus volumineux en termes de données à transmettre. Dans un autre exemple de réalisation, l’implémentation de l’aléa est mise en œuvre par une technique de tirage d’aléa et d’application d’un module (i.e. application d’un module sur le nombre obtenu), le module étant également aléatoire. Plus particulièrement, le module (modulo) est aléatoirement obtenu par le serveur intermédiaire (par exemple « 34 ») et un aléa (par exemple « 29) est déterminé également aléatoirement à l’intérieur de l’intervalle entre 1 et le module aléatoire (ici « 34 »). Dans un tel cas de figure, on a deux aléas : le module M i et le l’aléa dans le module a M . Ils sont transmis à l’application en charge de la saisie sur le terminal à écran tactile. En reprenant l’exemple précédent : l’utilisateur appuie sur la touche du caractère « c » de valeur « 9 » : la fonction f Ts obfusquée calcule (c+ a M ) modulo M i , c’est-à-dire (9+29). mod( 34)=4 et transmet 4 au terminal de vérification. Pour le caractère suivant, un nouveau module et un nouvel aléa sont utilisés. Les modules, comme dans le cas précédent de la permutation aléatoire, peuvent être transmis à l’avance (comme la table de permutation) ou bien un module peut être transmis pour chaque caractère. L’avantage de ce deuxième exemple d’implémentation, par rapport au premier est de pouvoir transmettre deux aléas, court, pour chaque caractère, ce qui n’est pas nécessairement possible avec la permutation aléatoire, particulièrement lorsque le clavier est étendu (cas d’un clavier complet de type « azerty » ou « qwerty » pour la saisi d’un mot de passe par exemple). Dans un autre exemple de réalisation, on utilise à la fois la technique de la permutation aléatoire et la technique du module. Cela peut par exemple être le cas pour un clavier de caractères numériques (dix caractères de [0] à [9]) et de deux touches de fonction (« Annulation », Validation »), soit douze touches au total. Dans cette situation La fonction f Ts obfusquée permet à partir d’un évènement d’appui de touche {x ;y } de générer un indice aléatoire. Cela passe par une première étape qui transforme l’appui de touche en un indice compris entre zéro et douze. Avec ces douze caractères, on peut calculer modulo 13 (nombre premier), donc on peut générer des permutations assez facilement ce nombre. Une permutation est générée : la fonction f Ts , c’est une permutation aléatoire qui est composée d’une transformation affine à base de deux nombres aléatoires qui sont tirés de l’aléa, et ils sont utilisés « modulo 13 ». Avec ce modulo 13, toute fonction aléatoire crée une permutation. On arrive donc à permuter avec deux nombres seulement l’ensemble des caractères du clavier et l’on obtient simplement une permutation aléatoire. Comme exposé précédemment, l’aléa provient du serveur transactionnel intermédiaire. Le serveur connait la fonction f Ts donc il est capable de calculer la correspondance et de fournir une table de conversion inverse au terminal de vérification. En conséquence, le terminal de vérification de dispose pas de la logique puisqu’il n’implémente pas de fonction affine modulo 13. Il n’implémente qu’un accès à une ou plusieurs tables, qui proviennent du serveur et qui est modifiée à chaque saisie de PIN, voire à chaque saisie de caractère. Ainsi, même si un attaquant maitrise le logiciel du terminal de vérification, la seule information qui sera obtenu est un accès à une table, non enregistrée dans ce logiciel. Le terminal de communication implémente la logique de saisie de touche et de transmission des caractères aléatoires saisis au terminal de vérification. Il l’implémente grâce à l’aléa qui provient du serveur transactionnel intermédiaire et optionnellement, pour une sécurité accrue, grâce à des méthodes d’obfuscation (ainsi, cette fonction f Ts fonction qui transforme un appui touche en un caractère est complément obfusquée). L’obfuscation permet de rendre très difficile le reverse et la compréhension. La fonction f Ts est embarquée dans ou accessible pour l'application mobile sous une forme obfusqué (très difficile à comprendre). Soit cette fonction est disponible, sous la forme d’une API, à partir de l’application, soit cette fonction est directement intégrée dans l’application elle-même. Idéalement, cette fonction est implémentée au sein d’un élément d’exécution sécurisé du terminal à écran tactile (« secure element ») ou d’un environnement d’exécution sécurisé (« TEE »), afin de se prémunir encore plus des tentatives de fraudes. Une telle implémentation est décrite par la suite, bien qu’elle ne soit pas obligatoire pour garantir l’effet premier de sécurisation obtenu par la fonction f Ts obfusquée. Quel que soit le mode d’implémentation de l’aléa, à chaque appui sur le clavier virtuel de l’application, le caractère aléatoire est généré par la fonction f Ts obfusquée embarquée ou accessible pour l’application mobile. À chaque saisie de mot de passe ou de caractère, une nouvelle table de correspondance peut être calculée, permettant ainsi de protéger efficacement le mot de passe saisi. Par exemple, à la première saisie de caractère, l’utilisateur souhaite saisir la touche ‘1’ . Cette touche correspond, après transformation par la fonction f Ts obfusquée, au caractère aléatoire ‘6’ . L’application mobile transmet, par l’intermédiaire du canal de transmission sécurisé, le nombre ‘6’ au terminal de vérification, qui en appliquant la fonction inverse f Ts -1 retransforme la saisie en ‘1’ (i.e. en utilisant la table reçue en provenance du serveur intermédiaire). Lors de l’appui suivant, si l’utilisateur souhaite de nouveau appuyer sur la touche ‘1’ , une nouvelle touche correspondante ‘9’ est obtenue par la fonction fonction f Ts obfusquée. Le terminal de vérification, en appliquant à nouveau la transformation inverse f Ts -1 obtient un ‘1’ (par un simple accès à une table de permutation inverse transmise par le serveur transactionnel intermédiaire). On décrit, en relation avec la , un procédé de mise en œuvre d’une transaction financière, en utilisant un terminal à écran tactile, requérant, pour la mise en œuvre de cette transaction, notamment l’obtention de données de paiement en provenance d’un moyen de paiement présenté par un utilisateur (l’exemple d’une carte de paiement sans contact est utilisé). Dans le procédé présenté en , la fonction fTs est mise en œuvre pour la saisie d’un code PIN en conjonction avec l’obtention de données en provenance de la carte sans contact. On note que le procédé peut également être mis en œuvre, avec une carte avec contact (terminal de paiement classique disposant d’un écran tactile pour la saisie du code PIN) ou pour un paiement réalisé par l’intermédiaire d’un terminal de communication d’un utilisateur (avec ou sans utilisation d’une carte de paiement, les données de paiement pouvant déjà être enregistrées au sein du terminal mobile, i.e sous forme de « card on file »). Un tel procédé comprend : une étape (10) de démarrage de la transaction une étape d’établissement (20), avec le serveur transactionnel intermédiaire, d’une liaison de communication sécurisée ; une étape de réception (30), en provenance du serveur transactionnel intermédiaire, des données de configuration de la transaction (ParT), y inclus le ou les aléas et ses paramètres ; une étape d’obtention (40) des données de paiement (PyD), comprenant par exemple : une étape d’affichage (40-1), sur l’écran du terminal à écran, d’une demande d’apposer une carte de paiement sur le terminal à écran tactile ; une étape de lecture (40-2) des données en provenance de la carte de paiement apposée sur le terminal à écran tactile ; une étape d’affichage (50) d’un clavier virtuel (Vk) requérant la saisie d’un code d’identification personnel ; une étape de saisie (60), par l’utilisateur, d’une pluralité de chiffres du code d’identification personnel, sur le clavier virtuel (Vk), comprenant l’utilisation de la fonction f Ts et des données de la configuration (ParT) de la transaction délivrant une série (SCa) de chiffres aléatoires ; une étape de transmission (70), au terminal de vérification, par l’intermédiaire du canal sécurisé (ou d’un autre canal), de la série de chiffres aléatoires (SCa) ; l’étape de transmission est soit mise en œuvre une seule fois, pour toute la série, soit mise en œuvre dès qu’un chiffre est saisi par l’utilisateur ; une étape de décodage (80), par le terminal de vérification, de la série de chiffres aléatoires (SCa), délivrant série de chiffres d’origine (SCo) ; une étape de validation (90) de la transaction par le terminal de vérification ; une étape de transmission (100) du résultat de validation de la transaction au terminal à écran tactile et étape d’affichage, par le terminal à écran tactile, de ce résultat. Ainsi, même si le terminal à écran tactile est infecté ou compromis, il n’est pas possible d’intercepter et de comprendre correctement quels sont les chiffres effectifs saisis par l’utilisateur pour le code PIN, car ces chiffres sont aléatoirement générés par la fonction de transformation au moment de la saisie de ceux-ci. On présente, en relation avec la , une architecture simplifiée d’un terminal à écran tactile (TermEt) apte à effectuer le traitement d’une transaction tel que présenté précédemment. Un terminal à écran tactile comprend une mémoire 31, une unité de traitement 32 équipée par exemple d’un microprocesseur, et pilotée par un programme d’ordinateur 33. Le terminal à écran tactile comprend optionnellement : une mémoire sécurisée 34, qui peut être fusionnée avec la mémoire 31 (comme indiqué en pointillés, dans ce cas la mémoire 31 est une mémoire sécurisée), une unité de traitement sécurisée 35 équipée par exemple d’un microprocesseur sécurisée et de mesure physiques de protection (protection physique autour de la puce, par treillis, vias, etc. et protection sur les interfaces de transmission de données), et pilotée par un programme d’ordinateur 36 spécifiquement dédié à cette unité de traitement sécurisée 35, ce programme d’ordinateur 36 mettant en œuvre toute ou partie du procédé de traitement d’une transaction tel que précédemment décrit. Le groupe composé de l’unité de traitement sécurisée 35, de la mémoire sécurisée 34 et du programme d’ordinateur dédié 36 constitue la portion sécurisée (PS) du terminal à écran tactile. Dans au moins un mode de réalisation, la présente technique est mise en œuvre sous la forme d’un ensemble de programmes installé en partie ou en totalité sur cette portion sécurisée du terminal de traitement de transaction. Dans au moins un autre mode de réalisation, la présente technique est mise en œuvre sous la forme d’un composant dédié (CpX) pouvant traiter des données des unités de traitement et installé en partie ou en totalité sur la portion sécurisée du terminal de traitement de transaction. Par ailleurs, le terminal comprend également des moyens de communication (CIE) se présentant par exemple sous la forme de composants réseaux (WiFi, 3G/4G/5G, filaire) qui permettent au terminal de recevoir des données (I) en provenance d’entités connectées à un ou plusieurs réseaux de communication et des transmettre des données traitées (T) à de telles entités. Un tel terminal comprend, en fonction des modes de réalisation : des moyens d’obtention de données en provenance de dispositifs transactionnels présentés des utilisateurs (carte d’accès, carte de transaction, etc.; ces moyens peuvent se présenter, par exemple, sous la forme de lecteur de cartes à puces, ou encore de lecteurs de cartes sans contact de type NFC ou de type RFID) ; des moyens d’obtention d’aléa et de paramétrage d’aléas en provenance d’un serveur transactionnel intermédiaire ; des moyens de saisie, permettant à l’utilisateur de saisir une ou plusieurs données pour la mise en œuvre de la transaction, lorsque cela est nécessaire (notamment des moyens de génération d’un clavier sur un écran tactile) des moyens de traitement des données obtenues par les moyens d’obtention de données en provenance des dispositifs transactionnels et des moyens de traitement des données saisies par l’utilisateurs ; des moyens de mise en œuvre d’une fonction de transformation sécrète obfusquée f Ts , ; des moyens de fourniture de données à un ou plusieurs terminaux de vérification ; Comme explicité précédemment, ces moyens sont par exemple mis en œuvre par l’intermédiaire de modules et/ou de composants, par exemple sécurisés. Ils permettent ainsi d’assurer la sécurité des transactions réalisées tout en garantissant une plus grande maintenabilité du terminal. On présente, en relation avec la , une architecture simplifiée d’un serveur transactionnel intermédiaire (STi) apte à effectuer le traitement d’une transaction tel que présenté précédemment. Un serveur transactionnel intermédiaire (STi) comprend une mémoire 41, une unité de traitement 42 équipée par exemple d’un microprocesseur, et pilotée par un programme d’ordinateur 43. Par ailleurs, le serveur transactionnel intermédiaire (STi) comprend également des moyens de communication (CIE) se présentant par exemple sous la forme de composants réseaux (WiFi, 3G/4G/5G, filaire) qui permettent au serveur transactionnel intermédiaire (STi) de recevoir des données (I) en provenance d’entités (terminal transactionnel, serveur décisionnaire) connectées à un ou plusieurs réseaux de communication et des transmettre des données traitées (T) à de telles entités. Un tel serveur transactionnel intermédiaire (STi) comprend, en fonction des modes de réalisation : des moyens de détermination d’une résolution d’un écran tactile d’un terminal sur lequel une donnée doit être saisie ; des moyens de génération d’au moins une donnée représentative d’un aléa (Dra, ParT), optionnellement en fonction de données (DRT) représentatives d’une résolution d’écran de l’écran tactile du terminal électronique (TermEt) ; des moyens de transmission de ladite au moins une donnée représentative d’un aléa (Dra, ParT) au terminal électronique (TermEt) , et des moyens de transmission, à un terminal de vérification, d’une table de décodage de caractères saisis sur ledit écran tactile du Terminal électronique (TermEt). Un terminal de vérification apte à effectuer le traitement d’une transaction tel que présenté précédemment, comprend une mémoire, une unité de traitement équipée par exemple d’un microprocesseur, et pilotée par un programme d’ordinateur. Le terminal à écran tactile comprend également : une mémoire sécurisée, qui peut optionnellement être fusionnée avec la mémoire, une unité de traitement sécurisée équipée par exemple d’un microprocesseur sécurisée et de mesure physiques de protection (protection physique autour de la puce, par treillis, vias, etc. et protection sur les interfaces de transmission de données), et pilotée par un programme d’ordinateur spécifiquement dédié à cette unité de traitement sécurisée, ce programme d’ordinateur mettant en œuvre toute ou partie du procédé de traitement d’une transaction tel que précédemment décrit. Le groupe composé de l’unité de traitement sécurisée de la mémoire sécurisée et du programme d’ordinateur dédié constitue la portion sécurisée du terminal à écran tactile. Dans au moins un mode de réalisation, la présente technique est mise en œuvre sous la forme d’un ensemble de programmes installé en partie ou en totalité sur cette portion sécurisée du terminal de traitement de transaction. Dans au moins un autre mode de réalisation, la présente technique est mise en œuvre sous la forme d’un composant dédié pouvant traiter des données des unités de traitement et installé en partie ou en totalité sur la portion sécurisée du terminal de traitement de transaction. Par ailleurs, le terminal comprend également des moyens de communication se présentant par exemple sous la forme de composants réseaux (WiFi, 3G/4G/5G, filaire) qui permettent au terminal de recevoir des données en provenance d’entités connectées à un ou plusieurs réseaux de communication et des transmettre des données traitées à de telles entités. Un tel terminal de vérification comprend, en fonction des modes de réalisation : des moyens de réception, en provenance du terminal électronique (TermEt) comprenant un écran tactile, de données représentatives d’un caractère aléatoire (DrCa) obtenues par l’exécution d’une fonction de transformation f Ts , de données représentatives de coordonnées ( x,y ) d’appui sur la dalle tactile du terminal, à l’aide de ladite au moins une donnée représentative d’un aléa (Dra, ParT) ; des moyens de conversion des données représentatives des caractères aléatoires (DrCa) en caractères effectivement saisis, ce moyens se présentant notamment sous la forme d’une table de conversion inverse transmise par le serveur transactionnel intermédiaire ; des moyens de validation des caractères effectivement saisis pour une validation d’une transaction, comme par exemple une transaction de paiement. Procédé de traitement de données issue d’une saisie sur un écran tactile, procédé mis en œuvre au sein d’un terminal électronique (TermEt) comprenant un écran tactile sur lequel les données sont saisies, ledit terminal électronique comprenant des moyens de connexion à serveur transactionnel intermédiaire (Sti), procédé caractérisé en ce qu’il comprend : une étape de réception (A01), en provenance du serveur transactionnel intermédiaire ( Sti ) auquel le terminal à écran tactile (TermEt) est connecté par l’intermédiaire l’une liaison sécurisée, d’au moins une donnée représentative d’un aléa (Dra, ParT) ; une étape de réception (A02), en provenance d’un contrôleur (CtrlDT) de dalle tactile, de données représentatives de coordonnées ( x,y ) d’appui sur la dalle tactile du terminal ; une étape de transformation (A03), par l’intermédiaire d’une fonction de transformation f Ts , desdites données représentatives de coordonnées ( x,y ) d’appui sur la dalle tactile du terminal, à l’aide de la dite au moins une donnée représentative d’un aléa (Dra, ParT), délivrant une donnée représentative d’un caractère aléatoire (DrCa) ; une étape de transmission (A04), de la donnée représentative d’un caractère aléatoire (DrCa) à un terminal de vérification. Procédé de traitement selon la revendication 1 caractérisé en ce que l’étape de transformation (A03) comprend l’application de la fonction de transformation suivante : C sa est un caractère aléatoire obtenu, qui est transmis sous la forme de la donnée représentative d’un caractère aléatoire (DrCa); R est une résolution de l’écran ; x est l’abscisse des données représentatives de coordonnées ( x,y ) ; y est l’ordonnée des données représentatives de coordonnées ( x,y ) ; a est un aléa inséré dans la calcul, aléa obtenu à partir de ladite moins une donnée représentative d’un aléa (Dra, ParT) ; Procédé de traitement selon la revendication 2 caractérisé en ce que la fonction de transformation met en œuvre une permutation aléatoire, générée par le serveur transactionnel intermédiaire (Sti) et reçue au moins en partie par le terminal électronique (TermEt). Procédé de traitement selon la revendication 2 caractérisé en ce que la fonction de transformation met en œuvre une fonction de module, dont les paramètres ont aléatoirement été déterminés par le serveur transactionnel intermédiaire (Sti) et reçue au moins en partie par le terminal électronique (TermEt). Procédé de traitement selon la revendication 1 caractérisé en ce qu’il comprend en outre, préalablement à l’étape de réception (A01), de ladite au moins une donnée représentative d’un aléa (Dra, ParT), une étape optionnelle de transmission (A00), au serveur transactionnel intermédiaire (STi), de données (DRT) représentatives d’une résolution d’écran de l’écran tactile du terminal électronique (TermEt). Procédé de traitement selon la revendication 1 caractérisé en ce qu’il est mis en œuvre lors de l’exécution d’une transaction électronique de paiement impliquant la saisie, par un utilisateur, d’un code d’identification personnel (PIN) sur l’écran tactile du terminal électronique (TermEt). Terminal électronique (TermEt) comprenant un écran tactile sur lequel des données sont saisies, ledit terminal électronique comprenant des moyens de connexion à serveur transactionnel intermédiaire (Sti), terminal caractérisé en ce qu’il comprend : des moyens de réception (A01), en provenance du serveur transactionnel intermédiaire ( Sti ) auquel le terminal à écran tactile (TermEt) est connecté par l’intermédiaire l’une liaison sécurisée, d’au moins une donnée représentative d’un aléa (Dra, ParT) ; des moyens de réception (A02), en provenance d’un contrôleur (CtrlDT) de dalle tactile, de données représentatives de coordonnées ( x,y ) d’appui sur la dalle tactile du terminal ; des moyens de transformation (A03), par l’intermédiaire d’une fonction de transformation f Ts , desdites données représentatives de coordonnées ( x,y ) d’appui sur la dalle tactile du terminal, à l’aide de la dite au moins une donnée représentative d’un aléa (Dra, ParT), délivrant une donnée représentative d’un caractère aléatoire (DrCa) ; des moyens de transmission (A04), de la donnée représentative d’un caractère aléatoire (DrCa) au serveur transactionnel intermédiaire (Sti). Serveur transactionnel intermédiaire, serveur du type comprenant une unité centrale, une mémoire et des moyens de réception et de transmission de données en provenance d’un réseau de communication, serveur comprenant : des moyens de détermination de données (DRT) représentatives d’une résolution d’un écran tactile d’un Terminal électronique (TermEt) sur lequel une donnée doit être saisie ; des moyens de génération d’au moins une donnée représentative d’un aléa (Dra, ParT), optionnellement en fonction des données (DRT) représentatives d’une résolution d’écran de l’écran tactile du terminal électronique (TermEt) ; des moyens de transmission de ladite au moins une donnée représentative d’un aléa (Dra, ParT) au terminal électronique (TermEt) , et des moyens de transmission, à un terminal de vérification, d’une table de décodage de caractères saisis sur ledit écran tactile du Terminal électronique (TermEt). Terminal de vérification de validité de données saisies sur un écran tactile d’un terminal à écran tactile, terminal du type comprenant une unité centrale, une mémoire et des moyens de réception et de transmission de données en provenance d’un réseau de communication, terminal comprenant des moyens de de réception, en provenance d’un serveur transactionnel intermédiaire, d’une table de décodage de caractères saisis sur ledit écran tactile du Terminal électronique (TermEt) ; des moyens des moyens de réception, en provenance du terminal électronique (TermEt) comprenant un écran tactile, de données représentatives d’un caractère aléatoire (DrCa) obtenues par l’exécution d’une fonction de transformation f Ts , de données représentatives de coordonnées (x,y) d’appui sur la dalle tactile du terminal, à d’au moins une donnée représentative d’un aléa (Dra, ParT) ; des moyens de conversion des données représentatives des caractères aléatoires (DrCa) en caractères effectivement saisis ; des moyens de validation des caractères effectivement saisis pour une validation d’une transaction. Système de traitement de données issue d’une saisie sur un écran tactile, système caractérisé en en qu’il comprend un Terminal électronique (TermEt) selon la revendication 7, un serveur transactionnel intermédiaire selon la revendication 8 et un terminal de vérification selon la revendication 9. Produit programme d’ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu’il comprend des instructions de code de programme pour l’exécution d'un procédé de traitement selon l’une des revendications 1 à 6, lorsqu’il est exécuté sur un ordinateur.