FR 3070078 A1 20190215 FR 1757645 A 20170810 Procédés et dispositifs de sécurisation de transmission de données entre un terminal et un lecteur de cartes, et produits programme d'ordinateur correspondants. 1 DOMAINE TECHNIQUE Le domaine de l'invention est celui du traitement de données transactionnelles mises en oeuvre notamment dans le cadre d'une opération de paiement. L'invention se rapporte plus particulièrement à la sécurisation de la transmission de données transactionnelles (par exemple un code PIN (pour « Personal Identification Number » en anglais)) dans le cadre d'une transaction, notamment une transaction de paiement, menée conjointement par un terminal de communication permettant la saisie de données et par un lecteur de cartes, notamment un lecteur de cartes bancaires, connecté à ce terminal de communication. L'invention a de nombreuses applications, notamment mais non exclusivement dans les domaines marchands impliquant un paiement en situation de mobilité pour lequel un appairage entre un lecteur de cartes bancaires (ou terminal de paiement) et un terminal de communication est d'intérêt. 2 ARRIERE-PLAN TECHNOLOGIQUE Le paiement en situation de mobilité est un enjeu majeur de développement 20 économique. Plus particulièrement, il existe un nombre grandissant de situations dans lesquelles un professionnel a besoin de pouvoir assurer une transaction de paiement (par exemple un paiement par carte bancaire) dans une situation de mobilité. Une telle situation se rencontre par exemple pour les professionnels qui sont en déplacement 25 constant pour leur activité professionnelle : professionnels libéraux, chauffeurs privés, etc. De tels professionnels notamment, que nous appelons par la suite commerçants au sens large, ont besoin de recevoir des paiements de la part de leurs clients mais n'ont pas nécessairement la possibilité de s'équiper d'un terminal de paiement autonome 2 ayant des capacités de fonctionnement nomades pour recevoir de tels paiements (par exemple à cause du prix de tels terminaux). Pour cette raison, des solutions alternatives ont été développées. C'est par exemple le cas des solutions proposées par la société SquareTM. Il est ainsi proposé un 5 lecteur de cartes bancaire qui vient se brancher sur la prise jack d'un terminal de communications. Un tel lecteur de cartes bancaires est par exemple présenté dans le document de brevet US9324100. Ce document de brevet décrit plus particulièrement un lecteur de cartes positionné dans un boîtier de faibles dimensions. Une tête de lecture magnétique est configurée pour être couplée à un dispositif mobile et le lecteur de 10 cartes dispose d'une fente pour balayer une bande magnétique d'une carte. La tête de lecture lit les données sur la bande magnétique et produit un signal représentatif des données stockées sur la bande magnétique. Une prise de sortie, ici de type jack, est adaptée pour être insérée dans un port du dispositif mobile et délivrer un signal de sortie au dispositif mobile en question. Alternativement, des solutions de connexion par 15 l'intermédiaire d'un port USB (pour « Universal Serial Bus » en anglais) sont proposées en lieu et place de l'utilisation du port jack. D'autres solutions existent, notamment pour permettre l'utilisation d'une carte à puce à la place (ou en complément) d'une carte à bande magnétique. Par ailleurs, certaines solutions ne nécessitent pas de connexion physique entre le terminal de communication et le lecteur de cartes : une connexion sans fil (par exemple de type Bluetooth) est envisageable. L'inconvénient est que le lecteur de cartes doit être muni de ses propres moyens d'alimentation. Ces solutions permettent ainsi au commerçant de recevoir un paiement par l'intermédiaire de son terminal mobile (par exemple un smartphone). Cette solution présente cependant un problème lié à l'absence de, ou à la faible, sécurisation des données de paiement saisies sur le terminal même du commerçant. En effet, avec certains types de cartes bancaires à bande magnétique, il est nécessaire d'effectuer une signature manuscrite pour valider le paiement. Dans ce cas, l'utilisateur utilise un stylet et/ou un doigt pour signer sur l'écran du terminal de communication du commerçant. Avec d'autres types de cartes bancaires à bande 3 magnétique, de même qu'avec des cartes à puce, il est nécessaire de saisir un code d'identification personnel, ou code PIN (pour « Personal Identification Number » en anglais), pour valider la transaction. Pour saisir ce code PIN, l'utilisateur utilise un clavier virtuel affiché sur l'écran du terminal de communication pour entrer son code PIN. 5 Un tel élément d'identification personnel (code PIN ou signature) saisi sur l'écran du terminal est alors transmis au lecteur de cartes qui gère la fin de la transaction de manière sécurisée. Cependant, quand bien même un tel lecteur de cartes possède tous les attributs permettant la gestion sécurisée de la transaction en question (par exemple en intégrant 10 les fonctionnalités requises au sein d'un élément de sécurisation (ou « secure element » en anglais) au sens de la norme PCI PTS (pour « Payment Card Industry PIN Transaction Security » en anglais)), le terminal mobile du commerçant n'intègre a priori pas systématiquement de tels éléments. De la sorte, la transmission de l'élément d'identification personnel saisi sur 15 l'écran du terminal au lecteur de cartes devient potentiellement un maillon faible de la chaine de traitement sécurisée de la transaction, un tiers pouvant intercepter l'élément d'identification personnel en question. Il existe ainsi un besoin d'une solution de sécurisation de la transmission de données, par exemple l'élément d'identification personnel, saisies sur un terminal 20 (notamment un terminal mobile) au lecteur de cartes finalisant la transaction afin de garantir l'intégrité de la transaction de paiement en question. 3 RESUME Selon l'invention, il est ainsi proposé procédé de réception sécurisée, dans un 25 lecteur de cartes, d'au moins une donnée entrée sur un terminal connecté au lecteur de cartes. Un tel procédé comprend les étapes suivantes, mises en oeuvre par le lecteur de cartes : obtention d'une clé de chiffrement du lecteur de cartes, dite clé lecteur ; 4 encryptage de la clé lecteur, à l'aide d'une clé de chiffrement authentique, dite clé authentique, partagée entre le lecteur de cartes et un serveur d'authentification, délivrant une clé lecteur encryptée ; envoi, au serveur d'authentification, de la clé lecteur encryptée pour transmission 5 de la clé lecteur du serveur d'authentification vers le terminal ; réception d'une clé encryptée envoyée par le serveur d'authentification, dite clé terminal encryptée, la clé terminal encryptée résultant d'un encryptage d'une clé de chiffrement obtenue par le serveur d'authentification, dite clé terminal, à l'aide de la clé authentique ; et 10 réception d'au moins une donnée encryptée envoyée par le terminal, résultant d'un encryptage à l'aide au moins de la clé lecteur et de la clé terminal de l'au moins une donnée. Ainsi, l'invention propose une solution nouvelle et inventive pour permettre la réception sécurisée, par le lecteur de cartes, de données (par exemple un élément 15 d'identification personnel du type code PIN, signature, etc.) entrées sur le terminal auquel est connecté le lecteur de cartes (par exemple via une saisie sur un écran tactile du terminal) afin que le lecteur de cartes en question puisse finaliser la transaction de paiement. Pour ce faire, la technique revendiquée propose de se baser sur une clé de 20 chiffrement authentique, partagée entre le lecteur de cartes et un serveur d'authentification du lecteur de cartes en question, afin de permettre au lecteur de cartes et au terminal d'échanger de manière sécurisée des clés de chiffrement (c'est-à-dire les clés lecteur et terminal) leur permettant de sécuriser leurs échanges subséquents. 25 Par exemple, le partage de la clé authentique est effectué en usine, lors d'une étape d'enregistrement du lecteur de cartes nouvellement fabriqué sur le serveur d'authentification. De la sorte, il est assuré que la clé authentique ne peut être interceptée par un tiers. Dans un mode de réalisation, la clé lecteur et la clé terminal sont des clés 30 publiques pour la mise en oeuvre d'un protocole de chiffrement asymétrique entre le 5 lecteur de cartes et le terminal, l'au moins une donnée encryptée résultant d'un encryptage mettant en oeuvre le protocole de chiffrement asymétrique. Ainsi, les données échangées entre le terminal et le lecteur de cartes sont encryptées selon une technique robuste et efficace basée sur la génération d'une paire 5 de clés, publique et privée, de part et d'autre du lien de transmission à sécuriser, les clés publiques étant échangées entre les deux entités en question. Par ailleurs, la méthode revendiquée permet de garantir, via l'usage de la clé authentique, qu'aucun tiers ne peut intercepter l'une des clés publiques en question et lui substituer une clé publique frauduleuse (une telle clé publique frauduleuse utilisée 10 par le lecteur de cartes et/ou le terminal permettant au tiers (connaissant la clé privée associée) de décrypter les messages cryptés à l'aide de la clé publique frauduleuse en question). Dans un mode de réalisation, le procédé comprend en outre une étape d'obtention d'au moins une clé symétrique secrète partagée entre le lecteur de cartes et 15 le terminal par mise en oeuvre d'un algorithme du type Diffie-Hellman, au moins un échange de données entre le lecteur de cartes et le terminal pour la mise en oeuvre de l'algorithme utilisant le protocole de chiffrement asymétrique. L'au moins une donnée encryptée résulte d'un encryptage additionnel à l'aide de la clé symétrique secrète. Ainsi, la sécurisation de l'échange de données entre le lecteur de cartes et le 20 terminal est renforcée. Dans un mode de réalisation, l'au moins une donnée est une donnée d'identification personnelle saisie sur un écran tactile du terminal. Ainsi, le lecteur de cartes reçoit la donnée d'identification personnelle (par exemple le code PIN ou la signature) saisie sur l'écran du terminal afin de pouvoir 25 finaliser la transaction de paiement de manière sécurisée. Dans un autre mode de réalisation de l'invention, il est proposé un procédé de sécurisation d'une réception, dans un lecteur de cartes, d'au moins une donnée entrée sur un terminal connecté au lecteur de cartes. Un tel procédé de sécurisation comprend les étapes suivantes, mises en oeuvre par un serveur d'authentification du lecteur de 30 cartes : 6 une obtention d'une clé de chiffrement du terminal, dite clé terminal ; un encryptage de la clé terminal à l'aide d'une clé de chiffrement authentique, dite clé authentique, partagée entre le lecteur de cartes et le serveur d'authentification, délivrant une clé terminal encryptée ; 5 un envoi, au lecteur de cartes, de la clé terminal encryptée ; une réception d'une clé lecteur encryptée, envoyée par le lecteur de cartes, la clé lecteur encryptée résultant d'un encryptage d'une clé de chiffrement du lecteur de cartes, dite clé lecteur, à l'aide de la clé authentique ; et une transmission, au terminal, de la clé lecteur. 10 Ainsi, l'invention concerne également un procédé de sécurisation de la réception, par le lecteur de cartes, de données (par exemple un élément d'identification personnel du type code PIN, signature, etc.) entrées sur le terminal auquel est connecté le lecteur de cartes (par exemple via une saisie sur un écran tactile du terminal) afin de pouvoir finaliser la transaction de paiement. 15 Pour ce faire, la méthode revendiquée propose qu'un serveur d'authentification du lecteur de cartes assure l'échange de clés de chiffrement (c'est-à-dire les clés lecteur et terminal) entre le lecteur de cartes et l'application de manière sécurisée en se basant sur une clé authentique partagée entre le lecteur de cartes et le serveur en question. Comme discuté ci-dessus, le partage de la clé authentique en question est effectué par 20 exemple en usine, lors d'une étape d'enregistrement sur le serveur d'authentification du lecteur de. De la sorte, il est assuré que la clé authentique ne peut être interceptée par un tiers, garantissant par là-même l'échange sécurisé des clés de chiffrement utilisées par le lecteur de cartes et le terminal pour leurs échanges. Dans un mode de réalisation, l'obtention comprend une réception de la clé 25 terminal envoyée par le terminal. Ainsi, le terminal peut générer une clé de chiffrement à chaque nouvelle session de communication avec le lecteur de cartes. Dans d'autres modes de réalisation, une telle clé terminal peut être prédéfinie et préalablement stockée dans le serveur d'authentification via une étape de 30 référencement du terminal auprès du serveur. Dans ce cas, la clé est obtenue par le 7 serveur via une identification du terminal et la lecture en mémoire de la clé terminal correspondante. Dans un mode de réalisation, au moins la transmission de la clé lecteur et/ou la réception de la clé terminal met en oeuvre un protocole TLS (pour « Transport Layer 5 Security » en anglais). Ainsi, l'échange d'informations entre le terminal et le serveur d'authentification est également sécurisé quand bien même le terminal ne partage pas la clé authentique avec le serveur d'authentification. Dans un mode de réalisation des procédés de réception sécurisée et de 10 sécurisation d'une réception, la clé authentique est une clé authentique de base. L'étape d'encryptage de la clé lecteur, respectivement de la clé terminal, comprend : une mise à jour d'un numéro de série de clé délivrant un numéro de série de clé misà-jour ; et une génération d'une clé authentique mise-à-jour sur la base de la clé authentique 15 de base et du numéro de série de clé mis-à-jour, la clé lecteur encryptée, respectivement la clé terminal encryptée, étant générée à l'aide de la clé authentique mise-à-jour. L'étape d'envoi de la clé lecteur encryptée au serveur d'authentification, respectivement de la clé terminal encryptée au lecteur de cartes, comprend un envoi du numéro de 20 série de clé mis-à-jour. Ainsi, la clé authentique est mise à jour avant chaque encryptage de la clé lecteur par le lecteur de carte, ou de la clé terminal par le serveur d'authentification (par exemple à chaque début de session d'une communication entre le lecteur de cartes et le terminal en pratique). Le numéro de série de clé mis-à-jour est alors transmis avec la clé 25 encryptée (clé lecteur ou clé application encryptée) afin de permettre au dispositif recevant la clé encryptée de mettre à jour la clé authentique de manière adéquate pour vérifier la validité de la clé encryptée en question. Dans un mode de réalisation des procédés de réception sécurisée et de sécurisation d'une réception, l'étape d'encryptage de la clé lecteur, respectivement de 30 la clé terminal, comprend une génération, à l'aide de la clé authentique ou de la clé 8 authentique mise-à-jour, d'un code d'authentification de message de la clé lecteur, respectivement de la clé terminal. L'étape d'envoi de la clé lecteur encryptée au serveur d'authentification, respectivement de la clé terminal encryptée au lecteur de cartes, comprend un envoi du code d'authentification de message. 5 Ainsi, la clé lecteur ou terminal encryptée est générée selon une technique éprouvée et efficace. Dans un mode de réalisation des procédés de réception sécurisée et de sécurisation d'une réception, l'étape d'envoi de la clé lecteur encryptée au serveur d'authentification, respectivement de la clé terminal encryptée au lecteur de cartes, 10 comprend un envoi de la clé lecteur, respectivement de la clé terminal. L'étape de réception de la clé terminal encryptée par le lecteur de cartes, respectivement de la clé lecteur encryptée par le serveur d'authentification, comprend : une génération d'une clé authentique mise-à-jour candidate sur la base de la clé authentique de base et du numéro de série de clé mis-à-jour envoyé par le serveur 15 d'authentification, respectivement le lecteur de cartes ; une génération, à l'aide de la clé authentique mise-à-jour candidate, d'un code d'authentification de message candidat de la clé terminal envoyée par le serveur d'authentification, respectivement de la clé lecteur envoyée par le lecteur ; et une comparaison du code d'authentification de message candidat et du code 20 d'authentification de message envoyé par le serveur d'authentification, respectivement par le lecteur de cartes ; la clé terminal envoyée par le serveur d'authentification, respectivement de la clé lecteur envoyée par le lecteur, étant acceptée par le lecteur de cartes, respectivement par le serveur d'authentification, lorsque la comparaison indique que le code 25 d'authentification de message candidat est identique au code d'authentification de message envoyé par le serveur d'authentification, respectivement le lecteur de cartes. Ainsi, la comparaison entre le code d'authentification de message candidat, généré à l'aide de la clé authentique de base (partagée entre le lecteur de cartes et le serveur d'authentification), et le code d'authentification de message reçu, permet de 30 valider que la clé lecteur reçue, respectivement la clé terminal reçue, n'est pas une clé 9 substituée par un tiers, mais bien la clé que le lecteur de carte, respectivement le serveur d'authentification, a envoyé. Dans un mode de réalisation des procédés de réception sécurisée et de sécurisation d'une réception, l'étape de transmission, au terminal, de la clé lecteur est 5 mise en oeuvre lorsque la comparaison indique que le code d'authentification de message candidat est identique au code d'authentification de message envoyé par le lecteur de cartes. Ainsi, le serveur d'authentification n'envoie la clé lecteur au terminal que lorsque la validité de la clé lecteur en question est avérée. 10 Dans un mode de réalisation des procédés de réception sécurisée et de sécurisation d'une réception, le terminal est un smartphone. Dans un mode de réalisation des procédés de réception sécurisée et de sécurisation d'une réception, le lecteur de cartes respecte une norme PCI PTS de traitement de données de transaction de paiement. 15 L'invention concerne également un programme d'ordinateur comprenant des instructions de code de programme pour la mise en oeuvre d'un procédé de réception sécurisée ou d'un procédé de sécurisation d'une réception (selon l'un quelconque de ses différents modes de réalisation), lorsqu'il est exécuté sur un ordinateur. Dans un autre mode de réalisation de l'invention, il est proposé un dispositif de 20 réception sécurisée, dans un lecteur de cartes, d'au moins une donnée entrée sur un terminal connecté au lecteur de cartes. Un tel dispositif comprend une machine de calcul reprogrammable ou une machine de calcul dédiée configurée pour : obtenir une clé de chiffrement du lecteur de cartes, dite clé lecteur ; encrypter la clé lecteur, à l'aide d'une clé de chiffrement authentique, dite clé 25 authentique, partagée entre le lecteur de cartes et un serveur d'authentification, délivrant une clé lecteur encryptée ; envoyer, au serveur d'authentification, de la clé lecteur encryptée pour transmission de la clé lecteur du serveur d'authentification vers le terminal ; recevoir une clé encryptée envoyée par le serveur d'authentification, dite clé 30 terminal encryptée, la clé terminal encryptée résultant d'un encryptage d'une clé de 10 chiffrement obtenue par le serveur d'authentification, dite clé terminal, à l'aide de la clé authentique ; et recevoir au moins une donnée encryptée envoyée par le terminal, résultant d'un encryptage à l'aide au moins de la clé lecteur et de la clé terminal de l'au moins une 5 donnée. Un tel dispositif de réception sécurisée est notamment apte à mettre en oeuvre le procédé de réception sécurisée selon l'invention (selon l'un quelconque des différents modes de réalisation précités). Ainsi, les caractéristiques et avantages de ce dispositif sont les mêmes que ceux 10 du procédé de réception sécurisée décrit précédemment. Par conséquent, ils ne sont pas détaillés plus amplement. Dans un autre mode de réalisation de l'invention, il est proposé un dispositif de sécurisation d'une réception, dans un lecteur de cartes, d'au moins une donnée entrée sur un terminal connecté au lecteur de cartes. Un tel dispositif comprend une machine 15 de calcul reprogrammable ou une machine de calcul dédiée configurée pour : obtenir une clé de chiffrement du terminal, dite clé terminal ; encrypter la clé terminal à l'aide d'une clé de chiffrement authentique, dite clé authentique, partagée entre le lecteur de cartes et le serveur d'authentification, délivrant une clé terminal encryptée ; 20 envoyer, au lecteur de cartes, la clé terminal encryptée ; recevoir une clé lecteur encryptée, envoyée par le lecteur de cartes, la clé lecteur encryptée résultant d'un encryptage d'une clé de chiffrement du lecteur de cartes, dite clé lecteur, à l'aide de la clé authentique ; et transmettre, au terminal, la clé lecteur. 25 Un tel dispositif de sécurisation d'une réception est notamment apte à mettre en oeuvre le procédé de sécurisation d'une réception selon l'invention (selon l'un quelconque des différents modes de réalisation précités). Ainsi, les caractéristiques et avantages de ce dispositif sont les mêmes que ceux du procédé de sécurisation d'une réception décrit précédemment. Par conséquent, ils 30 ne sont pas détaillés plus amplement. 11 4 LISTE DES FIGURES D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante, donnée à titre d'exemple indicatif et non limitatif, et des dessins 5 annexés, dans lesquels : la figure 1 illustre un lecteur de cartes connecté à un terminal en communication avec un serveur d'authentification du lecteur de cartes selon un mode de réalisation de l'invention ; la figure 2 illustre des étapes d'un procédé de réception sécurisée, par le lecteur 10 de cartes de la figure 1, d'au moins une donnée entrée sur le terminal auquel est connecté le lecteur de cartes en question selon un mode de réalisation de l'invention ; la figure 3 illustre des étapes d'un procédé de sécurisation de la réception, par le lecteur de cartes de la figure 1, d'au moins une donnée entrée sur le terminal 15 auquel est connecté le lecteur de cartes en question selon un mode de réalisation de l'invention ; la figure 4 présente un exemple simplifié de structure d'un dispositif destiné à mettre en oeuvre le procédé de réception sécurisée de données de la figure 2; et 20 la figure 5 présente un exemple simplifié de structure d'un dispositif destiné à mettre en oeuvre le procédé de sécurisation de la réception de données de la figure 3. 5 DESCRIPTION DETAILLEE DE L'INVENTION 25 Sur toutes les figures du présent document, les éléments et étapes identiques sont désignés par une même référence. Le principe général de la technique décrite repose sur l'utilisation d'une clé de chiffrement authentique partagée entre un lecteur de cartes et un serveur d'authentification du lecteur en question, afin de permettre l'échange de manière 30 sécurisé, via le serveur d'authentification en question, de clés de chiffrement spécifiques 12 entre ce lecteur de cartes et un terminal mobile auquel est connecté le lecteur de cartes. Par exemple, ce partage de la clé authentique est effectué en usine, pendant la fabrication du lecteur de cartes, lors d'une étape d'enregistrement du lecteur de cartes 5 en question sur le serveur d'authentification. De la sorte, il est assuré que la clé authentique ne peut être interceptée par un tiers, garantissant par là même l'échange sécurisé des clés de cryptage utilisées par le lecteur de cartes et le terminal pour leurs échanges de données subséquents. On décrit maintenant, en relation avec la figure 1, un lecteur de cartes 110 10 connecté à un terminal 100 en communication avec un serveur d'authentification 140 du lecteur de cartes 110 selon un mode de réalisation de l'invention. Plus particulièrement, le lecteur de cartes 110 est un lecteur de cartes à puce sécurisé apte à finaliser une transaction bancaire auprès d'un serveur (non représenté) d'une banque concernée par la transaction en question. Dans ce sens, le lecteur de 15 cartes 110 intègre toutes les fonctionnalités de sécurité correspondantes telles que requises par l'industrie du paiement par cartes, notamment l'intégration des fonctionnalités de sécurité en question au sein d'un élément de sécurisation tel que requis par les normes PCI PTS. Cependant, contrairement aux lecteurs connus, le lecteur de cartes 110 20 n'intègre pas de moyens permettant de saisir de données d'identification personnelle, ici le code PIN associé à la carte à puce lue 150. A contrario, le terminal 100, par exemple un smartphone, auquel est connecté (10) le lecteur de cartes 110 (par exemple via un lien physique du type USB ou jack, ou un lien radio du type Bluetooth) intègre un écran tactile 100e sur lequel le code PIN est saisi. Plus particulièrement, une application 25 de saisie est mise en oeuvre sur le terminal 100 afin de gérer la saisie sécurisée du code PIN sur l'écran tactile 100e. De la sorte, pour payer à l'aide de sa carte bancaire 150, un utilisateur présente (51) cette dernière au lecteur de cartes 110, mais saisit son code PIN sur l'écran tactile 100e. Le code PIN est alors transmis (10) au lecteur de cartes 110, sous une forme 13 cryptée comme détaillé par la suite, afin que ce dernier finalise la transaction de paiement. Dans des variantes, la carte bancaire est une carte à bande magnétique et la donnée d'identification personnelle peut notamment être soit une signature de 5 l'utilisateur, soit un code PIN saisi sur l'écran tactile 100e. Dans d'autres variantes, le lecteur de cartes peut intégrer un clavier de saisie de caractères, le code PIN restant saisi sur l'écran tactile 100e du terminal 100 afin de finaliser la transaction bancaire. Dans d'autres modes de réalisation non représentés, le code PIN (ou plus 10 généralement une donnée d'identification) est saisi non pas sur l'écran tactile 100e, mais sur un clavier physique du terminal 100 ou par tout autre moyen adéquat. Quel que soit le mode de réalisation ou la variante considéré, se pose le problème de la transmission sécurisée de la donnée d'identification personnelle saisie sur le terminal 100 au lecteur de cartes 110 afin que ce dernier finalise la transaction de 15 paiement. Afin de sécuriser cette transmission, un protocole de cryptage basé sur l'usage au moins d'une clé de chiffrement utilisée par le terminal 100, dite clé terminal 100ct, et une clé utilisée par le lecteur de cartes 110, dite clé lecteur 110c1, est utilisé par ces deux entités pour crypter les données qu'elles s'échangent. 20 Cependant, le lecteur de cartes 110 n'a pas la connaissance a priori du terminal 100 auquel il va être connecté, et réciproquement. De la sorte, se pose le problème de l'échange sécurisé des deux clés de chiffrement 110c1, 100ct au moment de l'appairage du lecteur de cartes 110 et du terminal 100 de sorte qu'un tiers ne puisse les intercepter et/ou substituer une clé frauduleuse à l'une d'elles ou aux deux (par exemple par une 25 attaque dite de l'homme du milieu). Pour sécuriser cet échange des deux clés de chiffrement 110c1, 100ct, la technique de l'invention propose que le lecteur de cartes 110 envoie la clé lecteur 110c1 au terminal 100 (par exemple à l'application de saisie qui gère la saisie sécurisée du code PIN sur l'écran tactile 100e) via un serveur d'authentification 140 du lecteur de cartes 14 110. Réciproquement, le terminal 100 envoie la clé terminal 100ct au lecteur de cartes 110 via le serveur d'authentification 140 en question. En effet, comme décrit ci-dessous en relation avec les figures 2 et 3, le serveur d'authentification 140 et le lecteur de cartes 110 partagent une clé de chiffrement 5 authentique, dite clé authentique 140ca, permettant de sécuriser les échanges entre ces deux entités. Par exemple, le partage de la clé authentique 140ca est effectué en usine, lors d'une étape d'enregistrement sur le serveur d'authentification 140 du lecteur de cartes 110 nouvellement fabriqué. De la sorte, il est assuré que la clé authentique 140ca ne peut être interceptée par un tiers, garantissant par là-même l'échange ultérieur de 10 manière sécurisée, via le serveur d'authentification 140, des clés de chiffrement 110c1, 100ct utilisées par le lecteur de cartes 110 et le terminal 100 pour leurs échanges. Par ailleurs, les échanges (40) entre le serveur d'authentification 140 et le terminal 100, bien que non cryptés à l'aide de la clé authentique 140ca (clé qui est non connue a priori du terminal 100), se font via une connexion internet sécurisée, par 15 exemple à l'aide d'un protocole TLS (pour « Transport Layer Security » en anglais).. De la sorte, l'échange des clés lecteur 110c1 et terminal 100ct se fait de manière sécurisée de bout en bout. Indépendamment de la forme logique (en termes de cryptage, protocole, etc. tels que décrits ci-dessus) que prennent les échanges entre le lecteur de cartes 110, le 20 terminal 100 et le serveur d'authentification 140, les données échangées empruntent le lien physique existant entre le terminal 100 et le serveur d'authentification 140. Plus particulièrement, le terminal 100 est un terminal mobile communiquant selon un standard de radiocommunication cellulaire (par exemple 2G, 3G, 4G, etc.) avec une station de base 120 du réseau cellulaire correspondant. Les données échangées 25 entre le serveur d'authentification 140 et le terminal 100 (soit à destination du terminal 100 lui-même, soit à destination du lecteur de cartes 110, et sur la base du cryptage ou du protocole de sécurité correspondant à la destination en question comme décrit ci-dessus) empruntent alors le canal radio entre ces deux entités. Dans une variante, les données échangées entre le serveur d'authentification 30 140 et le terminal 100 transitent (flèches en pointillés) par un serveur de gestion 130 de 15 l'application de saisie de saisie qui gère la saisie sécurisée du code PIN sur l'écran tactile 100e. On décrit maintenant, en relation avec les figures 2 et 3, les étapes d'un procédé de réception sécurisée (figure 2), ainsi que d'un procédé de sécurisation de la réception 5 (figure 3), par le lecteur de cartes 110, d'au moins une donnée entrée sur le terminal 100 selon un mode de réalisation de l'invention. Lors d'une étape E200 (figure 2) mise en oeuvre par le lecteur de cartes 110, la clé lecteur 110c1 est obtenue par le lecteur de cartes 110. Plus particulièrement, la clé lecteur 110c1 est une clé publique associée à une clé 10 lecteur privée afin de mettre en place un protocole de chiffrement asymétrique pour l'échange de données entre le lecteur de cartes 110 et le terminal 100. Dans une variante, la paire constituée par la clé lecteur 110c1 et la clé lecteur privée associée est générée à chaque nouvelle session initiant une communication avec le terminal 100. 15 Dans une autre variante, la paire constituée par la clé lecteur 110c1 et la clé lecteur privée associée est prédéfinie et est stockée dans une mémoire sécurisée du lecteur de cartes 110. De la sorte, la clé lecteur 110c1 est obtenue par lecture de la mémoire sécurisée en question dans cette variante. Lors d'une étape E210 (figure 2) mise en oeuvre par le lecteur de cartes 110, la 20 clé lecteur 110c1 obtenue lors de l'étape E200 est encryptée par le lecteur de cartes 110 à l'aide de la clé authentique 140ca partagée avec le serveur authentique 140. Une clé lecteur encryptée est ainsi délivrée. Pour ce faire, lors d'une sous-étape E210a, un numéro de série de clé est mis-àjour au début de la nouvelle session initiant une communication avec le terminal 100. 25 Lors d'une sous-étape E210b, une clé authentique mise-à-jour, ou clé de session, est générée sur la base de la clé authentique 140ca (qui est alors considérée comme une clé authentique de base) et du numéro de série de clé mis-à-jour délivré lors de la sous-étape E210a. Une telle génération de la clé authentique mise-à-jour se fait par exemple selon la méthode définie dans la norme ANSI X9.24-1. 16 Lors d'une sous-étape E210c, la clé lecteur encryptée est généré sous la forme d'un code d'authentification de message de la clé lecteur 110c1 à l'aide de la clé authentique mise à jour. Une telle génération du code d'authentification de message se fait par exemple selon la méthode définie dans la norme ISO 9797-1. 5 Lors d'une étape d'envoi E220 (figure 2), la clé lecteur encryptée délivrée lors de l'étape E210 est envoyée au serveur d'authentification 140 pour transmission subséquente de la clé lecteur 110c1 depuis le serveur d'authentification 140 vers le terminal 100. Plus particulièrement, lors d'une sous-étape E220a, le numéro de série de clé 10 mis-à-jour délivré lors de la sous-étape E210a est envoyé au serveur d'authentification 140. De même, lors d'une sous-étape E220b, le code d'authentification de message de la clé lecteur 110c1 est également envoyé au serveur d'authentification 140. Enfin, lors d'une sous-étape E220c, la clé lecteur 110c1 est également envoyée 15 au serveur d'authentification 140. Dans certains modes de réalisation (non illustrés), les trois sous-étapes d'envoi E220a, E220b, E220c précitées sont réalisées en seulement une ou deux étapes d'envoi des informations correspondantes qui sont alors combinées pour envoi simultané. Sur la base de ces trois informations, le serveur d'authentification 140 est alors 20 apte à vérifier que la clé lecteur 110c1 reçu du lecteur de cartes 110 est bien la clé publique du lecteur de cartes 110, et non une clé substituée par un tiers. Pour ce faire, lors d'une étape de réception E330 (figure 3) mise en oeuvre par le serveur d'authentification 140, le serveur d'authentification 140 reçoit la clé lecteur encryptée. 25 Plus particulièrement, l'étape de réception E330 comprend les sous-étapes suivantes afin de contrôler que la clé lecteur 110c1 n'est pas une clé substituée : - lors d'une sous-étape E330a, une clé authentique mise-à-jour candidate est générée sur la base de la clé authentique 140ca (qui est alors considérée comme une clé authentique de base) et du numéro de série de clé mis-à-jour reçu du 30 lecteur de cartes 110. Une telle génération se fait sur la base des mêmes 17 opérations que celles décrites ci-dessus en relation avec la sous-étape E210b de génération, par le lecteur de cartes 110, de la clé authentique mise-à-jour, ou clé de session, utilisée pour le cryptage de la clé lecteur 110c1; - lors d'une sous-étape E330b, un code d'authentification de message candidat de 5 la clé lecteur 110c1 est généré à l'aide de la clé authentique mise-à-jour candidate ; et - lors d'une sous-étape E330c, une comparaison est effectuée entre le code d'authentification de message candidat et le code d'authentification de message. 10 Plus particulièrement, la clé lecteur 110c1 est acceptée par le serveur d'authentification 140 lorsque les deux codes d'authentification de message en question sont identiques. En effet, dans ce cas il est assuré que la clé reçue par le serveur d'authentification 140 lors de l'étape de réception E330 est bien la clé lecteur 110c1 et donc que cette dernière n'a pas été substituée par un tiers durant la transmission entre 15 le lecteur de cartes 110 et le serveur d'authentification 140. Lors d'une étape E340 (figure 3) mise en oeuvre par le serveur d'authentification 140, le serveur d'authentification 140 transmet la clé lecteur 110c1 reçue lors de l'étape E330 au terminal 100. Plus particulièrement, l'étape E340 est mise en oeuvre lorsque la sous-étape 20 E330c de comparaison entre le code d'authentification de message candidat et le code d'authentification de message indique que les deux codes d'authentification de message en question sont identiques. Par ailleurs, comme discuté ci-dessus en relation avec la figure 1, l'envoi de la clé lecteur 110c1 par le serveur d'authentification 140 au terminal 100 se fait via une 25 connexion sécurisée à l'aide d'un protocole TLS. De la sorte, quand bien même l'échange de données entre le serveur d'authentification 140 et le terminal 100 n'est pas crypté à l'aide de la clé authentique 140ca (clé qui est non connue a priori du terminal 100), la sécurité des données transmises reste garantie. Symétriquement aux étapes E200, E210 et E230 mises en oeuvre par le lecteur 30 de cartes 110 et décrites ci-dessus, le serveur d'authentification 140 met de son côté en 18 oeuvre les étapes E300, E310 et E330 (figure 3) pour respectivement obtenir la clé terminal 100ct, encrypter ladite clé, et envoyer au lecteur de cartes 110 la clé terminal encryptée ainsi obtenue. Plus particulièrement, lors de l'étape E300 (figure 3) le serveur 5 d'authentification 140 obtient la clé terminal 100ct. Pour ce faire, lors d'une sous-étape E300a, le serveur d'authentification 140 reçoit la clé terminal 100ct envoyée par le terminal 100 via la connexion sécurisée par le protocole TLS comme décrit ci-dessus. Plus particulièrement, la clé terminal 100ct est une clé publique associée à une 10 clé terminal privée afin de mettre en place un protocole de chiffrement asymétrique pour l'échange de données entre le lecteur de cartes 110 et le terminal 100. Dans une variante, la paire constituée par la clé terminal 100ct et la clé terminal privée associée est générée à chaque nouvelle session initiant une communication avec le terminal 100. 15 Dans d'autres modes de réalisation (non illustrés), la clé terminal 100ct est prédéfinie et préalablement stockée dans le serveur d'authentification 140 via une étape de référencement du terminal 100 auprès du serveur d'authentification 140. Dans ce cas, la clé terminal 100ct est obtenue par le serveur d'authentification 140 via une identification du terminal 100 et la lecture en mémoire de la clé terminal 100ct 20 correspondante. De même, lors d'une étape E310 (figure 3), le serveur d'authentification 140 encrypte la clé terminal 100ct obtenue lors de l'étape E300 à l'aide de la clé authentique 140ca partagée avec le lecteur de cartes 110. Une clé terminal encryptée est ainsi délivrée. 25 Le serveur d'authentification 140 exécute alors les mêmes opérations que celles exécutées par le lecteur de cartes 110 lors des sous-étapes E210a, E210b et E210c décrites ci-dessus. Plus particulièrement, lors d'une sous-étape E310a, un numéro de série de clé est mis-à-jour au début de la nouvelle session initiant une communication avec le 30 lecteur de cartes 110. 19 Lors d'une sous-étape E310b, une clé authentique mise-à-jour, ou clé de session, est générée sur la base de la clé authentique 140ca (qui est alors considérée comme une clé authentique de base) et du numéro de série de clé mis-à-jour délivré lors de la sous-étape E310a. 5 Lors d'une sous-étape E310c, la clé terminal encryptée est générée sous la forme d'un code d'authentification de message de la clé terminal 100ct à l'aide de la clé authentique mise-à-jour. Enfin, lors d'une étape d'envoi E320 (figure 3), la clé terminal encryptée délivrée lors de l'étape E310 est envoyée au lecteur de cartes 110. 10 Le serveur d'authentification 140 exécute alors les mêmes opérations que celles exécutées par le lecteur de cartes 110 lors des sous-étapes E220a, E220b et E220c décrites ci-dessus. Plus particulièrement, lors d'une sous-étape E320a, le numéro de série de clé mis-à-jour délivré lors de la sous-étape E310a est envoyé au lecteur de cartes 110. 15 De même, lors d'une sous-étape E320b, le code d'authentification de message de la clé terminal 100ct est également envoyé au lecteur de cartes 110. Enfin, lors d'une sous-étape E320c, la clé terminal 110ct est également envoyée au lecteur de cartes 110. Dans certains modes de réalisation (non illustrés), les trois sous-étapes d'envoi 20 E320a, E320b, E320c précitées sont réalisées en seulement une ou deux étapes d'envoi des informations correspondantes qui sont alors combinées pour envoi simultané. Suite à l'étape d'envoi E320 mise en oeuvre par le serveur d'authentification 140, le lecteur de cartes 110, est apte à vérifier, sur la base des trois informations reçues, que la clé terminal 100ct reçue du serveur d'authentification 140 est bien la clé publique du 25 terminal 100, et non une clé substituée par un tiers. Pour ce faire, le lecteur de cartes 110 exécute alors les mêmes opérations que celles exécutées par le serveur d'authentification 140 lors des sous-étapes E330a, E330b et E330c décrites ci-dessus. Plus particulièrement, lors d'une étape de réception E230 (figure 2), le lecteur de 30 cartes 110 reçoit la clé terminal 100ct sous une forme encryptée, dite clé terminal 20 encryptée, envoyée par le serveur d'authentification 140. Une telle étape de réception E230 comprend les sous-étape suivantes afin de contrôler que la clé terminal 100ct n'est pas une clé substituée : - lors d'une sous-étape E230a, une clé authentique mise-à-jour candidate est 5 générée sur la base de la clé authentique 140ca (qui est alors considérée comme une clé authentique de base) et du numéro de série de clé mis-à-jour reçu du serveur d'authentification 140 ; - lors d'une sous-étape E230b, un code d'authentification de message candidat de la clé terminal 100ct est généré à l'aide de la clé authentique mise-à-jour 10 candidate ; et - lors d'une sous-étape E230c, une comparaison est effectuée entre le code d'authentification de message candidat et le code d'authentification de message. Plus particulièrement, la clé terminal 100ct est acceptée par le lecteur de cartes 15 lorsque les deux codes d'authentification de message en question sont identiques. En effet, dans ce cas il est assuré que la clé reçue par le lecteur de cartes 110 lors de l'étape de réception E230 est bien la clé terminal 100ct et donc que cette dernière n'a pas été substituée par un tiers. A l'issue de la mise en oeuvre des étapes précitées, le lecteur de cartes 110 a 20 obtenu de manière sécurisée la clé terminal 100ct, et le terminal 100 a obtenu de manière sécurisée la clé lecteur 110c1. De la sorte, l'échange de données sous forme cryptée entre le terminal 100 et le lecteur de cartes 110 peut commencer sur la base du protocole de chiffrement asymétrique basé sur les clés publiques terminal 100ct et lecteur 110c1. Notamment, le lecteur de cartes 110 est apte à recevoir de manière 25 sécurisée le code PIN saisi par l'utilisateur sur l'écran 100e du terminal 100. Cependant, afin de renforcer encore la sécurisation des échanges de données entre le lecteur de cartes 110 et le terminal 100, le lecteur de cartes 110 met en oeuvre une étape additionnelle E240 (figure 2) d'obtention d'une clé symétrique secrète partagée entre le lecteur de cartes 110 et le terminal 100. Une telle obtention est basée 30 sur un algorithme du type Diffie-Hellman (tel que défini par exemple dans la norme ANSI 21 X9.42) impliquant des échanges de données entre le lecteur de cartes 110 et le terminal 100. Les échanges en question utilisent alors le protocole de chiffrement asymétrique basé sur les clés publiques échangées entre le terminal 100 et le lecteur de cartes 110, c'est-à-dire les clés terminal 100ct et lecteur 110c1. 5 Lors d'une étape E250, le lecteur de cartes 110 reçoit du terminal 100 les données sous forme encryptées, par exemple le code PIN saisi sur l'écran tactile 100e du terminal 100. De telles données sont encryptées via l'usage du protocole de de chiffrement asymétrique précité considéré seul ou en combinaison avec le chiffrement additionnel 10 basé sur la clé symétrique secrète. De la sorte, le lecteur de cartes 110 est apte à finaliser la transaction de paiement de manière sécurisée auprès d'un serveur d'une banque concernée par la transaction en question. La figure 4 présente un exemple de structure d'un dispositif 110d de réception 15 sécurisée, dans le lecteur de cartes 110, d'au moins une donnée entrée sur le terminal 100. Plus particulièrement, un tel dispositif 110d permet la mise en oeuvre du procédé de la figure 2. Le dispositif 110d comprend une mémoire vive 403 (par exemple une mémoire RAM), une unité de traitement 402 équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur stocké dans une mémoire morte 401 (par 20 exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive 403 avant d'être exécutées par le processeur de l'unité de traitement 402. Cette figure 4 illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser les moyens compris dans le dispositif 110d, afin qu'il effectue 25 certaines étapes du procédé détaillé ci-dessus, en relation avec la figure 2 (dans l'un quelconque des différents modes de réalisation). En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d'instructions, ou sur une machine de calcul dédiée (par exemple un ensemble 30 de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel). Dans le 22 cas où les moyens compris dans le dispositif 110d sont réalisés avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d'instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage 5 étant lisible partiellement ou totalement par un ordinateur ou un processeur. Dans le mode de réalisation illustré sur la figure 1, un tel dispositif 110d est inclus dans le lecteur de cartes 110. Dans certaines variantes, le dispositif 110d est intégré au sein d'un élément de sécurisation tel que requis par les normes PCI PTS. 10 La figure 5 présente un exemple de structure d'un dispositif 140d de sécurisation d'une réception, dans le lecteur de cartes 110, d'au moins une donnée entrée sur le terminal 100. Plus particulièrement, un tel dispositif 140c1 permet la mise en oeuvre du procédé de la figure 3. Le dispositif 140c1 comprend une mémoire vive 503 (par exemple une mémoire RAM), une unité de traitement 502 équipée par exemple 15 d'un processeur, et pilotée par un programme d'ordinateur stocké dans une mémoire morte 501 (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive 503 avant d'être exécutées par le processeur de l'unité de traitement 502. Cette figure 5 illustre seulement une manière particulière, parmi plusieurs 20 possibles, de réaliser les moyens compris dans le dispositif 140d, afin qu'il effectue certaines étapes du procédé détaillé ci-dessus, en relation avec la figure 3 (dans l'un quelconque des différents modes de réalisation). En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une 25 séquence d'instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel). Dans le cas où les moyens compris dans le dispositif 140d sont réalisés avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d'instructions) pourra être stocké dans un médium de stockage amovible (tel que par 23 exemple une disquette, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur. Dans le mode de réalisation illustré sur la figure 1, un tel dispositif 140c1 est inclus dans le serveur d'authentification 140. 5 Dans certaines variantes, le dispositif 140c1 est intégré au sein d'un REVENDICATIONS1. Procédé de réception sécurisée, dans un lecteur de cartes (110), d'au moins une donnée entrée sur un terminal (100) connecté audit lecteur de cartes, caractérisé en ce qu'il comprend les étapes suivantes, mises en oeuvre par ledit lecteur de cartes : obtention (E200) d'une clé de chiffrement dudit lecteur de cartes, dite clé lecteur (110c1) ; encryptage (E210) de ladite clé lecteur, à l'aide d'une clé de chiffrement authentique, dite clé authentique (140ca), partagée entre ledit lecteur de cartes et un serveur d'authentification (140), délivrant une clé lecteur encryptée ; envoi (E220), audit serveur d'authentification, de ladite clé lecteur encryptée pour transmission de ladite clé lecteur dudit serveur d'authentification vers ledit terminal ; réception (E230) d'une clé encryptée envoyée par ledit serveur d'authentification, dite clé terminal encryptée, ladite clé terminal encryptée résultant d'un encryptage d'une clé de chiffrement obtenue par ledit serveur d'authentification, dite clé terminal (100ct), à l'aide de ladite clé authentique ; et réception (E250) d'au moins une donnée encryptée envoyée par ledit terminal, résultant d'un encryptage à l'aide au moins de ladite clé lecteur et de ladite clé terminal de ladite au moins une donnée. 2. Procédé selon la revendication 1, dans lequel ladite clé lecteur et ladite clé terminal sont des clés publiques pour la mise en oeuvre d'un protocole de chiffrement asymétrique entre ledit lecteur de cartes et ledit terminal, ladite au moins une donnée encryptée résultant d'un encryptage mettant en oeuvre ledit protocole de chiffrement asymétrique. 25 3. Procédé selon la revendication 2 comprenant en outre une étape d'obtention (E240) d'au moins une clé symétrique secrète partagée entre ledit lecteur de cartes et ledit terminal par mise en oeuvre d'un algorithme du type Diffie-Hellman, au moins un échange de données entre ledit lecteur de cartes et ledit terminal pour la mise en oeuvre 5 dudit algorithme utilisant ledit protocole de chiffrement asymétrique, et dans lequel l'au moins une donnée encryptée résulte d'un encryptage additionnel à l'aide de ladite clé symétrique secrète. 4. Procédé selon l'une quelconque des revendications 1 à 3 dans lequel ladite au 10 moins une donnée est une donnée d'identification personnelle saisie sur un écran tactile (100e) dudit terminal. 5. Procédé de sécurisation d'une réception, dans un lecteur de cartes (110), d'au moins une donnée entrée sur un terminal (100) connecté audit lecteur de cartes, 15 caractérisé en ce qu'il comprend les étapes suivantes, mises en oeuvre par un serveur d'authentification (140) dudit lecteur de cartes : une obtention (E300) d'une clé de chiffrement dudit terminal, dite clé terminal (100ct) ; un encryptage (E310) de ladite clé terminal à l'aide d'une clé de chiffrement 20 authentique, dite clé authentique (140ca), partagée entre ledit lecteur de cartes et ledit serveur d'authentification, délivrant une clé terminal encryptée ; un envoi (E320), audit lecteur de cartes, de ladite clé terminal encryptée ; une réception (E330) d'une clé lecteur encryptée, envoyée par ledit lecteur de cartes, 25 ladite clé lecteur encryptée résultant d'un encryptage d'une clé de chiffrement dudit lecteur de cartes, dite clé lecteur (110c1), à l'aide de ladite clé authentique ; et une transmission (E340), audit terminal, de ladite clé lecteur. 6. Procédé selon la revendication 5 dans lequel ladite obtention comprend une 30 réception (E300a) de ladite clé terminal envoyée par ledit terminal. 26 7. Procédé selon la revendication 5 ou 6 dans lequel au moins ladite transmission de ladite clé lecteur et/ou ladite réception de ladite clé terminal met en oeuvre un protocole TLS (pour « Transport Layer Security » en anglais). 5 8. Procédé selon l'une quelconque des revendications 1 à 7 dans lequel ladite clé authentique est une clé authentique de base, et dans lequel ladite étape d'encryptage de ladite clé lecteur, respectivement de ladite clé terminal, comprend : 10 une mise à jour (E210a, E310a) d'un numéro de série de clé délivrant un numéro de série de clé mis-à-jour ; et une génération (E210b, E310b) d'une clé authentique mise-à-jour sur la base de ladite clé authentique de base et dudit numéro de série de clé mis-à-jour, ladite clé lecteur encryptée, respectivement ladite clé terminal encryptée, étant 15 générée à l'aide de ladite clé authentique mise-à-jour ; et dans lequel ladite étape d'envoi de ladite clé lecteur encryptée audit serveur d'authentification, respectivement de ladite clé terminal encryptée audit lecteur de cartes, comprend un envoi (E220a, E320a) dudit numéro de série de clé mis-à-jour. 20 9. Procédé selon l'une quelconque des revendications 1 à 8 dans lequel ladite étape d'encryptage de ladite clé lecteur, respectivement de ladite clé terminal, comprend une génération (E210c, E310c), à l'aide de ladite clé authentique ou de ladite clé authentique mise-à-jour, d'un code d'authentification de message de ladite clé lecteur, respectivement de ladite clé terminal, 25 et dans lequel ladite étape d'envoi de ladite clé lecteur encryptée audit serveur d'authentification, respectivement de ladite clé terminal encryptée audit lecteur de cartes, comprend un envoi (E220b, E320b) dudit code d'authentification de message. 10. Procédé selon la revendication 9 en ce qu'elle dépend de la 8 dans lequel ladite 30 étape d'envoi de ladite clé lecteur encryptée audit serveur d'authentification, 27 respectivement de ladite clé terminal encryptée audit lecteur de cartes, comprend un envoi (E220c, E320c) de ladite clé lecteur, respectivement de ladite clé terminal, et dans lequel ladite étape de réception de ladite clé terminal encryptée par ledit lecteur de cartes, respectivement de ladite clé lecteur encryptée par ledit serveur 5 d'authentification, comprend : une génération (E230a, E330a) d'une clé authentique mise-à-jour candidate sur la base de ladite clé authentique de base et dudit numéro de série de clé mis-à-jour envoyé par ledit serveur d'authentification, respectivement ledit lecteur de cartes ; une génération (E230b, E330b), à l'aide de ladite clé authentique mise-à-jour 10 candidate, d'un code d'authentification de message candidat de ladite clé terminal envoyée par ledit serveur d'authentification, respectivement de ladite clé lecteur envoyée par ledit lecteur ; et une comparaison (E230c, E330c) dudit code d'authentification de message candidat et dudit code d'authentification de message envoyé par ledit serveur 15 d'authentification, respectivement par ledit lecteur de cartes ; ladite clé terminal envoyée par ledit serveur d'authentification, respectivement de ladite clé lecteur envoyée par ledit lecteur, étant acceptée par ledit lecteur de cartes, respectivement par ledit serveur d'authentification, lorsque ladite comparaison indique que ledit code d'authentification de message candidat est identique audit code 20 d'authentification de message envoyé par ledit serveur d'authentification, respectivement ledit lecteur de cartes. 11. Procédé selon la revendication 10 en ce qu'elle dépend de l'une quelconque des revendications 5 à 7 dans lequel ladite étape de transmission, audit terminal, de ladite 25 clé lecteur est mise en oeuvre lorsque ladite comparaison indique que ledit code d'authentification de message candidat est identique audit code d'authentification de message envoyé par ledit lecteur de cartes. 12. Produit programme d'ordinateur comprenant des instructions de code de 30 programme pour la mise en oeuvre d'un procédé selon l'une quelconque des 28 revendications 1 à 11, lorsque ledit programme est exécuté par un processeur. 13. Dispositif (110d) de réception sécurisée, dans un lecteur de cartes (110), d'au moins une donnée entrée sur un terminal (100) connecté audit lecteur de cartes, 5 caractérisé en ce qu'il comprend une machine de calcul reprogrammable (402) ou une machine de calcul dédiée configurée pour : obtenir une clé de chiffrement dudit lecteur de cartes, dite clé lecteur (110c1) ; encrypter ladite clé lecteur, à l'aide d'une clé de chiffrement authentique, dite clé authentique (140ca), partagée entre ledit lecteur de cartes et un serveur 10 d'authentification (140), délivrant une clé lecteur encryptée ; envoyer, audit serveur d'authentification, de ladite clé lecteur encryptée pour transmission de ladite clé lecteur dudit serveur d'authentification vers ledit terminal ; recevoir une clé encryptée envoyée par ledit serveur d'authentification, dite clé 15 terminal encryptée, ladite clé terminal encryptée résultant d'un encryptage d'une clé de chiffrement obtenue par ledit serveur d'authentification, dite clé terminal (100ct), à l'aide de ladite clé authentique ; et recevoir au moins une donnée encryptée envoyée par ledit terminal, résultant d'un 20 encryptage à l'aide au moins de ladite clé lecteur et de ladite clé terminal de ladite au moins une donnée. 14. Dispositif (140d) de sécurisation d'une réception, dans un lecteur de cartes (110), d'au moins une donnée entrée sur un terminal (100) connecté audit lecteur de 25 cartes, caractérisé en ce qu'il comprend une machine de calcul reprogrammable (502) ou une machine de calcul dédiée configurée pour : obtenir une clé de chiffrement dudit terminal, dite clé terminal (100ct) ; encrypter ladite clé terminal à l'aide d'une clé de chiffrement authentique, dite clé 30 authentique (140ca), partagée entre ledit lecteur de cartes et ledit serveur 29 d'authentification, délivrant une clé terminal encryptée ; envoyer, audit lecteur de cartes, ladite clé terminal encryptée ; recevoir une clé lecteur encryptée, envoyée par ledit lecteur de cartes, ladite clé lecteur encryptée résultant d'un encryptage d'une clé de chiffrement dudit 5 lecteur de cartes, dite clé lecteur (110c1), à l'aide de ladite clé authentique ; et transmettre, audit terminal, ladite clé lecteur.