Note : Les descriptions sont présentées dans la langue officielle dans laquelle elles ont été soumises.
CA 03029154 2018-12-21
WO 2018/002351
PCT/EP2017/066365
Procédé d'authentification de données de paiement, dispositifs et programmes
correspondants.
1. Domaine
L'invention se rapporte au domaine de la sécurisation des données échangées
par
l'intermédiaire d'un protocole de transmission de données sans contact. La
technique se
rapporte plus particulièrement à la transmission de données de type NEC, dans
laquelle on
effectue une transmission entre un premier dispositif et un deuxième
dispositif séparés d'une
distance de l'ordre d'une dizaine de centimètre au plus. La technique ne
s'applique pas et n'est
pas destinée à s'appliquer dans le cadre de techniques de transmission de
données de type
WiFi, WiMax, LTE, dont les technologies de transmission sont différentes.
2. Art Antérieur
De nombreux dispositifs de la vie quotidienne sont aptes à communiquer et à
échanger des données entre eux. Une part croissante de dispositifs utilisent,
pour ce faire, des
protocoles d'échange de données dit "en champ proches" ou encore NEC. Parfois,
ces
techniques de transmission de données sont également appelées RFID. Cette
appellation n'est
pas correcte puisque NEC signifie communication en champ proche, tandis que
RFID se
rapporte à des moyens d'identification par fréquence radio. Les deux utilisent
des signaux
radio pour toutes sortes de fins de repérage et de suivi, en remplaçant
parfois des codes à
barres. Toutes deux utilisent des moyens de transmission de données à courte
portée.
Or, l'utilisation de ce type de technologie suscite encore des craintes et des
interrogations de la part des utilisateurs. Nombreux sont ceux qui n'accordent
pas ou peu
confiance à ces technologies, plus particulièrement lorsqu'il s'agit de les
utiliser à des fins de
traitement de données personnelles et/ou confidentielles. C'est par exemple le
cas du
paiement. Relativement récemment, des dispositifs de paiement sans contact ont
fait leur
apparition. Il s'agit par exemple des cartes de paiement sans contact qui
permettent
d'effectuer un paiement (dont le montant est généralement plafonné) en
apposant (ou en
rapprochant) la carte de paiement d'un terminal de paiement compatible. Il
s'agit également
des terminaux de communication, qui intègrent également des "puces" sans
contact : ces
puces (également appelées "contactless chip") et qui offrent des capacités
d'échange de
données aux terminaux de communication, capacités qui peuvent être utilisées
pour effectuer
des paiements, un peu comme si le terminal de communication imitait le
comportement d'une
CA 03029154 2018-12-21
WO 2018/002351
PCT/EP2017/066365
2
carte de paiement sans contact. De nombreuses rumeurs, souvent infondées,
laissent
entendre qu'une communication ou qu'un paiement réalisé sans contact serait
peu sûr. Il est
également souvent rapporté que les dispositifs seraient peu sécurisés et qu'il
serait possible de
récupérer les données qui sont contenus dans ces dispositifs à l'insu de
l'utilisateur. Bien que
.. ces rumeurs soient souvent sans fondement, il existe cependant des risques
lors de la
transmission de données entre les dispositifs et notamment lors de la
transmission de données
de paiement. Les risques, cependant, ne proviennent pas de la technologie
employée, en elle-
même (NEC), mais généralement de l'utilisateur lui-même. Ainsi par exemple,
dans le cas d'un
terminal de communication utilisant l'interface NEC pour effectuer un
paiement, il est possible
que l'utilisateur ait installé une application peu sure, voire une application
malveillante, dont
l'objectif est d'utiliser des données de paiement à des fins de fraudes. La
situation est la même
du côté du terminal du commerçant.
Par exemple, dans le cadre d'une communication entre un dispositif
d'utilisateur (un
terminal de communication de type smartphone) et un terminal de paiement,
notamment en
.. utilisant des protocoles NEC pour le paiement, il est nécessaire que le
dispositif et le terminal
authentifie des données. A cette fin, le dispositif met en oeuvre un protocole
d'authentification
avec le terminal (par exemple un terminal de paiement, une borne d'un
marchand, ou tout
autre dispositif approprié). Le terminal contrôle que la phase
d'authentification a réussi et
dans le cas contraire refuse la transaction ou déclenche une alerte, ou met en
oeuvre tout
.. autre comportement jugé approprié dans une telle situation.
Dans les scénarios typiques, le terminal effectuant ces contrôles est, un
dispositif
sécurisé (comme un terminal de paiement). Il a été conçu pour prévenir la
plupart des types
possibles d'intrusion, tant matérielles que logicielles. Mais si le terminal
de paiement est un
dispositif tiers (terminal de communication de type tablette, smartphone,
écran), alors la
sécurité de ce terminal de communication (tiers) ne peut pas être garantie,
pas plus que
l'origine des applications installées sur ce terminal (par le commerçant lui-
même). Si le
commerçant n'est pas vigilant, il se peut que les applications installées sur
ce terminal soient
frauduleuses.
On présente ci-après un cas de dysfonctionnement possible, mis en oeuvre lors
d'un
paiement entre un terminal de communication et un dispositif d'utilisateur. On
appelle "V" le
CA 03029154 2018-12-21
WO 2018/002351
PCT/EP2017/066365
3
vérificateur (par exemple le terminal ou l'appareil du marchand) et "P" le
prouveur (dispositif
de l'utilisateur : smartphone, tablette).
Les protocoles de paiement travaillent habituellement de la façon suivante, au
cours
de la transaction : V demande à P de signer numériquement des données. P signe
les données,
conformément à ce qui est demandé par V et transmet les données signées à V.
Cette
signature est vérifiée par V, et si elle est correcte, alors la transaction
est acceptée et
transférée dans le reste de la chaîne de traitement des paiements. Une telle
procédure est
appelée un "défi-réponse" (challenge response) et est utilisée par exemple par
les
spécifications EMV.
Le problème auquel il est proposé de remédier est le suivant : si V fonctionne
sur un
dispositif non sécurisé (i.e. un terminal de type tablette, PC ou autre,
auquel on a adjoint des
fonctionnalités de paiement) qui est infecté par un logiciel malveillant
(installé par le
commerçant ou par un tiers mal intentionné), alors ce logiciel peut abuser le
terminal du client
P. Un tel abus peut par exemple prendre la forme d'une succession de
transactions (invisibles).
Ceci peut être réalisé par exemple lorsque le terminal du commerçant force le
dispositif de
l'utilisateur à signer des messages arbitraires. Le dispositif de
l'utilisateur, en position
d'esclave , est alors obligé de signer ces données. Le logiciel malveillant
installé sur le
terminal du commerçant se sert ensuite de ces données signées pour créer des
transactions
frauduleuses.
C'est le paradoxe de ces traitements cryptographiques : il est certain que les
traitements réalisés sont bons (car ils mettent en oeuvre des traitements
cryptographiques), en
revanche, l'utilisation qui est faite des résultats de ces traitements
cryptographiques ne peut
pas être garantie.
3. Résumé
L'invention ne pose pas ces problèmes de l'art antérieur. Plus
particulièrement,
l'invention apporte une solution simple à la problématique préalablement
identifiée. Cette
solution est entièrement compatible avec les dispositifs matériels existants.
Plus particulièrement, il est proposé un procédé d'authentification d'au moins
une
donnée, procédé mis en oeuvre lors d'une transaction de paiement intervenant
entre un
terminal d'un commerçant et un dispositif d'utilisateur, procédé qui comprend
la création d'un
triplet d'authentification, comprenant un code d'authentification et deux
composants de
CA 03029154 2018-12-21
WO 2018/002351
PCT/EP2017/066365
4
signature, ce triplet étant construit par la dispositif d'utilisateur et
n'étant vérifiable que par le
terminal du commerçant.
Pour ce faire, il est divulgué un procédé d'authentification d'au moins une
donnée,
procédé mis en oeuvre lors d'une transaction de paiement intervenant entre un
terminal de
communication d'un commerçant et un dispositif d'utilisateur, procédé du type
comprenant
l'authentification par le terminal de communication d'au moins un message m
générée par le
dispositif d'utilisateur, par l'intermédiaire d'une liaison de données sans
fils en champs proche,
procédé caractérisé en ce qu'il comprend, au sein du dispositif d'utilisateur
:
- une étape d'obtention, à partir du message m, d'une donnée aléatoire t et
d'une
fonction de hachage H, d'un code d'authentification Si ;
- une étape d'obtention, à partir du message m, de la donnée aléatoire t,
d'une clé
publique Z du terminal de communication, d'une première clé privée x du
dispositif
d'utilisateur et du code d'authentification Si, d'un premier composant de
signature 52;
- une étape d'obtention, à partir du message m, de la donnée aléatoire t,
de la clé
publique de Z du terminal de communication, d'une deuxième clé privée y du
dispositif
d'utilisateur et du code d'authentification Si, d'un deuxième composant de
signature
53;
- une étape de transmission, au terminal de communication, du code
d'authentification
Si, et des deux composants de signature 52 et 53.
Un tel procédé permet de créer un triplet qui peut être transmis au terminal
de
communication pour permettre une vérification, en aveugle, de la validité (et
de la
connaissance) par le dispositif d'utilisateur, du message m.
Selon un autre aspect, il est également divulgué un procédé d'authentification
qui
comprend, au sein du terminal de communication :
- une étape d'obtention, à partir du premier composant de signature 52,
d'une clé
publique X du dispositif d'utilisateur, d'une clé privée z du terminal de
communication,
et du code d'authentification Si, d'une première valeur de référence, notée
Ufrii;
- une étape d'obtention, à partir du deuxième composant de signature 53,
d'une clé
publique Y du dispositif d'utilisateur, de la clé privée z, et du code
d'authentification Si,
d'une deuxième valeur de référence, notée 142] ;
CA 03029154 2018-12-21
WO 2018/002351
PCT/EP2017/066365
- une étape de vérification que la première valeur de référence Iffrii est
égale à la
deuxième valeur de référence 142] ; et, lorsque les deux valeurs sont égales :
- une étape de vérification que la valeur H(142]) et/ou H(1./1rii) est
égale à Si.
- une étape de délivrance d'une assertion d'authentification lorsque
l'étape de
5 vérification précédente est positive.
Ainsi, sans avoir fait référence au message, il est possible de vérifier la
validité du
triplet reçu.
Selon un mode de réalisation particulier, le procédé comprend, pour ledit
dispositif
d'utilisateur, préalablement à ladite étape d'obtention d'un code
d'authentification, une phase
.. de détermination d'un ensemble de paramètres de chiffrement, comprenant :
- une étape d'obtention d'un groupe de Schnor (G) et d'un générateur de ce
groupe (g) ;
- une étape d'obtention de la première clé privée (x), ladite clé privée
étant un élément
du groupe G;
- une étape d'obtention de la deuxième clé privée (y), ladite clé privée
étant un élément
du groupe G ;
- une étape de calcul, à partir de la première clé privée (x), d'une clé
publique X telle
que X est une exponentiation du générateur g par la clé privée x, X=gx ;
- une étape de calcul, à partir de la première clé privée (y), d'une clé
publique Y telle
que Y est une exponentiation du générateur g par la clé privée y, Y=e.
Selon un mode de réalisation particulier, le procédé comprend, pour ledit
terminal de
communication du commerçant, préalablement à ladite étape d'obtention d'une
première
valeur de référence, une phase de détermination d'un ensemble de paramètres de
chiffrement, comprenant :
- une étape d'obtention d'un groupe de Schnor (G) et d'un générateur de ce
groupe (g) ;
- une étape d'obtention de la clé privée (z), ladite clé privée étant un
élément du groupe
G;
- une étape de calcul, à partir de la clé privée (z), d'une clé publique Z
telle que Z est une
exponentiation du générateur g par la clé privée z, Z=gz.
Selon un mode de réalisation particulier :
- l'étape
d'obtention du code d'authentification Si met en oeuvre le calcul suivant :
=
H(mlit), ou I I est l'opérateur de concaténation ;
CA 03029154 2018-12-21
WO 2018/002351
PCT/EP2017/066365
6
- l'étape d'obtention du premier composant de signature 52 met en oeuvre le
calcul
suivant : 52 = (Mi I t)Zel ;
- l'étape d'obtention du deuxième composant de signature 53 met en oeuvre
le calcul
suivant : 53 = I I tesl.
Selon un mode de réalisation particulier :
l'étape d'obtention de la première valeur de référence Iffrii met en oeuvre le
calcul
suivant : Ufrii = s2X-zsi ;
- l'étape d'obtention de la deuxième valeur de référence Ufr2J met en
oeuvre le calcul
suivant :142] = s3y-zsl.
Selon un autre aspect, il est également divulgué un dispositif d'utilisateur
comprenant
une unité de traitement général, une mémoire, dispositif comprenant une unité
de traitement
sécurisé et une mémoire sécurisée et au moins un circuit reconfigurable de
traitement de
transaction de paiement avec un terminal de communication comprenant notamment
une
authentification d'une donnée, ledit dispositif d'utilisateur comprenant :
- des moyens d'obtention, à partir du message m, d'une donnée aléatoire t
et d'une
fonction de hachage H, d'un code d'authentification Si ;
- des moyens d'obtention, à partir du message m, de la donnée aléatoire t,
d'une clé
publique Z du terminal de communication, d'une première clé privée x du
dispositif
d'utilisateur et du code d'authentification Si, d'un premier composant de
signature 52;
- des moyens d'obtention, à partir du message m, de la donnée aléatoire t,
de la clé
publique de Z du terminal de communication, d'une deuxième clé privée y du
dispositif
d'utilisateur et du code d'authentification Si, d'un deuxième composant de
signature
53;
- des moyens de transmission, au terminal de communication, du code
d'authentification Si, et des deux composants de signature 52 et 53.
Un tel dispositif d'utilisateur se présente généralement sous la forme d'un
terminal de
communication de type téléphone intelligent.
Selon un autre aspect, il est également divulgué un terminal de commerçant
comprenant une unité de traitement général, une mémoire, terminal caractérisé
comprenant
une unité de traitement sécurisé et une mémoire sécurisée et au moins un
circuit
reconfigurable de traitement de transaction de paiement avec un dispositif
d'utilisateur
CA 03029154 2018-12-21
WO 2018/002351
PCT/EP2017/066365
7
comprenant notamment une authentification d'une donnée, ledit terminal de
commerçant
comprenant :
- des moyens d'obtention, à partir du premier composant de signature 52,
d'une clé
publique X du dispositif d'utilisateur, d'une clé privée z du terminal de
communication,
et du code d'authentification Si, d'une première valeur de référence, notée
Ufrii;
- des moyens d'obtention, à partir du deuxième composant de signature .53,
d'une clé
publique Y du dispositif d'utilisateur, de la clé privée z, et du code
d'authentification Si,
d'une deuxième valeur de référence, notée 142] ;
- des moyens de vérification que la première valeur de référence Ufrii est
égale à la
deuxième valeur de référence Ufry ; et, lorsque les deux valeurs sont égales :
- des moyens de vérification que la valeur H(142]) et/ou H(1./1rii) est
égale à Si.
- des moyens de délivrance d'une assertion d'authentification lorsque
l'étape de
vérification précédente est positive.
Un tel terminal de commerçant peut se présenter sous la forme d'un terminal de
type
.. smartphone ou tablette. Un tel terminal peut également se présenter sous la
forme d'un
terminal de paiement auquel on adjoint les moyens précédemment décrits.
Selon une implémentation préférée, les différentes étapes des procédés selon
l'invention sont mises en oeuvre 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 module relais selon l'invention et étant conçu pour commander
l'exécution des
différentes étapes des procédés.
En conséquence, l'invention vise aussi un programme, susceptible d'être
exécuté par
un ordinateur ou par un processeur de données, ce programme comportant des
instructions
pour commander l'exécution des étapes d'un procédé tel que mentionné ci-
dessus.
Ce programme peut utiliser n'importe quel langage de programmation, et être
sous la
forme de code source, code objet, ou de code intermédiaire entre code source
et code objet,
tel que dans une forme partiellement compilée, ou dans n'importe quelle autre
forme
souhaitable.
L'invention 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.
CA 03029154 2018-12-21
WO 2018/002351
PCT/EP2017/066365
8
Le support d'informations peut être n'importe quelle entité ou dispositif
capable de
stocker le programme. Par exemple, le support peut comporter un moyen de
stockage, tel
qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou
encore un
moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou
un disque
dur.
D'autre part, le support d'informations peut être un support transmissible 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 l'invention 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, l'invention est mise en oeuvre au moyen de
composants
logiciels et/ou matériels. Dans cette optique, le terme "module" peut
correspondre dans ce
document aussi bien à un composant logiciel, qu'a 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 oeuvre une fonction ou un ensemble
de
fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Un tel
composant
logiciel est exécuté par un processeur de données d'une entité physique
(terminal, serveur,
passerelle, routeur, etc.) et est susceptible d'accéder aux ressources
matérielles de cette entité
physique (mémoires, supports d'enregistrement, bus de communication, cartes
électroniques
d'entrées/sorties, interfaces utilisateur, etc.).
De la même manière, un composant matériel correspond à tout élément d'un
ensemble matériel (ou hardware) apte à mettre en oeuvre une fonction ou un
ensemble de
fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut
s'agir d'un
composant matériel programmable ou avec 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.
CA 03029154 2018-12-21
WO 2018/002351
PCT/EP2017/066365
9
Chaque composante du système précédemment décrit met bien entendu en oeuvre
ses propres modules logiciels.
Les différents modes de réalisation mentionnés ci-dessus sont combinables
entre eux
pour la mise en oeuvre de l'invention.
4. Dessins
D'autres caractéristiques et avantages de l'invention apparaîtront plus
clairement à la
lecture de la description suivante d'un mode de réalisation préférentiel,
donné à titre de
simple exemple illustratif et non limitatif, et des dessins annexés, parmi
lesquels :
la figure 1 présente un synoptique de la technique proposée pour la création
d'éléments de signature à destination du terminal du commerçant ;
la figure 2 présente un synoptique de la technique proposée pour la
vérification
d'éléments de signature reçus d'un dispositif d'utilisateur ;
la figure 3 représente schématiquement un terminal de communication du
commerçant selon la présente ;
- la figure 4 décrit représente schématiquement un dispositif d'utilisateur
selon la
présente.
5. Description
5.1. Principe général
Comme explicité précédemment, le principe général de l'invention consiste
notamment à intégrer, en plus d'un schéma de "défi-réponse" (ou à la place de
ce schéma),
une ou plusieurs opérations additionnelles. La présente invention propose une
modification
protocolaire qui permet de résister aux attaques des terminaux comprenant des
logiciels
malveillants. A titre secondaire, cette modification protocolaire permet
également de protéger
les terminaux des commerçants eux-mêmes contre des réponses non sollicités
provenant
d'autres appareils (c'est à dire des appareils malveillants qui tenteraient
d'attaquer un terminal
de commerçant authentique). Cette modification protocolaire offrant ainsi une
couche
supplémentaire de protection contre d'autres types d'attaques (DoS "Denial of
Seryerce",
Concurency Attacks ¨ attaques par concurrence d'accès aux ressources-).
Classiquement, lorsqu'une transaction de paiement est effectuée entre un
terminal
d'un commerçant et un dispositif d'utilisateur, un processus de type
"challenge/response"
("défi/réponse" en français) est mis en oeuvre afin que le terminal du
commerçant identifie
CA 03029154 2018-12-21
WO 2018/002351
PCT/EP2017/066365
(authentifie) le dispositif d'utilisateur (et vice versa) par l'intermédiaire
de l'échange d'un
message m. La présente technique permet de se passer d'un schéma de ce type.
Il n'est ainsi
plus nécessaire de réaliser un processus de type défi réponse . La
technique mise en oeuvre
n'est donc pas une technique de type défi-réponse (qui est un processus
interactif) ; il ne
5 s'agit pas non plus d'une nouvelle signature (qui est vérifiable
publiquement) ; il ne s'agit pas
non plus d'un code d'authentification de message (qui n'est possible qu'en cas
de partage
d'une clé secrète).
Plus particulièrement, l'approche retenue par la présente technique est de
faire en
sorte que le dispositif de l'utilisateur puisse prouver qu'il a légitimement
signé le message
10 m (les données) à authentifier, sans pour autant avoir à transmettre
ce message (le
message peut par exemple être connu de part et d'autre : par le terminal du
commerçant et
par le dispositif d'utilisateur. Ainsi, au lieu de signer de manière
traditionnelle le message et de
le transmettre (c'est-à-dire de transmettre le message signé), on adopte une
stratégie de
transmission de preuve de signature de ce message (qui peut être
complémentaire soit à la
transmission de ce message, soit au partage de la connaissance du message
entre le terminal
du commerçant et le dispositif d'utilisateur).
On suppose que le terminal du commerçant n'est pas sécurisé en tant que tel
(il s'agit
d'un téléphone, d'une tablette ou d'un PC), mais qu'il dispose de ressources
de sécurisation.
Ces ressources de sécurisation peuvent par exemple prendre la forme d'un
"secure element -
SE" (élément sécurisé en français), d'un "Trusted Execution Environment - TEE"
(environnement d'exécution sécurisé en français) ou encore d'un autre
composant matériel ou
logiciel dédié. On suppose, pour les explications qui vont suivre, que
l'application de paiement
du terminal du commerçant s'appelle TPC, et qu'elle comprend un module de
vérification
(d'identification) appelé V (il s'agit par exemple d'un SE, d'un TEE ou plus
généralement d'une
unité de traitement sécurisée, qui peut même être distante, c'est-à-dire non
présente dans le
terminal). On suppose également qu'il existe une application de paiement sur
le dispositif
d'utilisateur DU, et que le dispositif de l'utilisateur (DU) comprend un
module de preuve (de
confirmation d'identité) appelé P (il s'agit par exemple d'un SE, d'un TEE ou
plus généralement
d'une unité de traitement sécurisée). Dans un autre mode de réalisation, le
dispositif
d'utilisateur peut être une carte de paiement classique, dans laquelle on a
effectué des
CA 03029154 2018-12-21
WO 2018/002351
PCT/EP2017/066365
11
modifications protocolaires et matérielles permettant de mettre en oeuvre la
présente
technique.
D'une manière générale, la présente technique combine les principes de
signatures de
Schnorr et d'échange de clés Diffie-Hellman (pour l'hypothèse d'absence de
solution
calculatoire). Toutefois, à la différence des signatures de Schnorr (qui
comprend un couple de
données), la technique mise en oeuvre utilise une signature comprenant un
triplet de données.
L'utilisation d'un tel triplet, en lieu et place d'un couple (tel que défini
dans la signature
de Schnorr) permet de de créer (de manière sécurisée) une restriction
supplémentaire : seul un
destinataire particulier peut vérifier la signature (à la différence des
signatures de Schnorr qui
sont publiquement vérifiables).
Par ailleurs, à la différence du procédé classique de Schnorr, la technique
repose sur
l'utilisation d'un couple de clé privées et d'un couple de clé publiques, qui
est mis à la
disposition du dispositif d'utilisateur (et/ou du module de preuve).
On décrit, en relation avec les figures 1 et 2, la technique proposée
authentifiant des
données entre un terminal de communication d'un commerçant et un dispositif
d'utilisateur.
Comme explicité précédemment, on suppose que V et P ont chacun, par leurs
propres
moyens, obtenus la connaissance des données à authentifier (le message m).
Lors de la mise
en oeuvre conjointe des applications de paiement TPC et DU, le procédé mis en
oeuvre est le
globalement le suivant :
- le module P calcule (10), à partir du message m, d'une donnée aléatoire t
et d'une
fonction de hachage H, un code d'authentification Si ;
- le module P calcule (20), à partir du message m, de la donnée
aléatoire t, d'une clé
publique Z de V, d'une première clé privée x de P et du code
d'authentification Si, un
premier composant de signature 52;
- le module P calcule (30), à partir du message m, de la donnée aléatoire
t, de la clé
publique de V, d'une deuxième clé privée de P et du code d'authentification
Si, un
deuxième composant de signature 53;
- le module P transmet (40), au terminal du commerçant (ou au module
V), le code
d'authentification Si, et les deux composants de signature 52 et 53.
Ces étapes, effectuées sur le dispositif d'utilisateur (ou le module P) sont
mises en
oeuvre sur la base d'une part de clés privées (deux) à disposition du
dispositif d'utilisateur et
CA 03029154 2018-12-21
WO 2018/002351
PCT/EP2017/066365
12
d'une clé publique du terminal du commerçant. Dans cet exemple, on suppose que
m est
connu de part et d'autre avant, et c'est juste l'aléa t qui est transmis, avec
(Si, 52, 53) qui
signe le message.
La clé publique du terminal du commerçant est soit transmise par le terminal
du
commerçant à l'initialisation de la transaction de paiement, soit obtenue, par
exemple à partir
d'une base de données, accessible depuis le dispositif d'utilisateur. La
donnée aléatoire t est,
quant à elle, unilatéralement choisie par le dispositif d'utilisateur. Il va
de soi que cette clé
publique devrait, selon les bonnes pratiques, être certifiée par une autorité
reconnue.
Toutefois cela n'est pas nécessaire au fonctionnement de l'invention, et n'est
même pas utile
dans certaines applications. La clé publique utilisée pour le destinataire de
la signature n'est
pas nécessairement la clé publique du terminal commerçant. Ce pourrait être
par exemple
celle du processeur de paiement (le module V), le terminal ne faisant que
relayer l'information.
A partir des données reçues (Si, 52 et 53), le terminal du commerçant (ou le
module V,
ou un destinataire distant), va vérifier (en réalisant un calcul sur ces
données) qu'elles sont
bien synonymes de la connaissance (par le dispositif d'utilisateur ou par P)
du message m.
Pour ce faire, le terminal du commerçant (ou le module V):
calcule (50), à partir du premier composant de signature 52, de la clé
publique X
(correspondant à la clé privée x), de sa propre clé privée z, et du code
d'authentification Si, une première valeur de référence, notée Iffrii
- calcule (60), à partir du deuxième composant de signature 53, de la clé
publique Y
(correspondant à la clé privée y), de sa propre clé privée z, et du code
d'authentification Si, une deuxième valeur de référence, notée 1.4.21;
vérifie (70) que la première valeur de référence Iffrii est égale à la
deuxième valeur de
référence 1421; et, lorsque les deux valeurs sont égales :
- vérifie (80) que la valeur H(142) est égale à Si.
Lorsque l'étape de vérification (80) est positive, le procédé délivre une
assertion
d'authentification. En fonction du résultat de cette vérification le procédé
une étape de
transmission (90), par le terminal de communication, d'une donnée de
validation de
transaction à un système de traitement de transaction de paiement (STTP).
Ainsi, lorsque les deux vérifications précédentes sont vraies, on en déduit
que le
dispositif d'utilisateur (ou le module P) connaît le message m. Pour mettre en
oeuvre le
CA 03029154 2018-12-21
WO 2018/002351
PCT/EP2017/066365
13
procédé tel que décrit précédemment, dans le cadre d'une opération de paiement
intervenant
entre le dispositif d'utilisateur et le terminal du commerçant, selon la
présente, il n'est
nécessaire de ne disposer (en commun) que deux éléments :
- la fonction de hachage H: cette fonction de hachage est utilisée par le
module P pour
calculer le premier code d'authentification Si et par le module V pour
vérifier que le
hachage de 142] est égal au premier code d'authentification Si ; Le module V
et le
module P partage donc la connaissance de cette fonction de Hachage ;
- des paires de {clés publiques ; clés privées} qui sont utilisées pour
créer les éléments
de signatures ;
- le message m: le message m est déterminé par le terminal du commerçant et
par le
dispositif d'utilisateur ;
A l'aide de la technique proposé, il n'est pas nécessaire que le dispositif
d'utilisateur
transmette la valeur de ce message m au terminal du commerçant : il suffit
qu'il transmette la
preuve qu'il en a connaissance. Comme le message m ne transite pas par le
réseau, il ne peut
pas être intercepté et modifié. Il n'est donc pas possible de modifier les
composantes de la
transaction de paiement.
Par ailleurs, à l'aide de cette technique, seul le terminal du commerçant (ou
le module
V) est en mesure de vérifier la validité des données transmises par le
dispositif d'utilisateur (ou
le module P). De plus, il n'est même pas nécessaire que le terminal du
commerçant (ou le
module V), dispose du message m. En effet, dans la technique proposée, le
message m n'est
pas utilisé par le commerçant : seul le code d'authentification S1 est
utilisé. Dès lors, le code
d'authentification S1 peut être utilisé comme preuve de la validité de la
transaction de
paiement, sans qu'il soit nécessaire, pour le terminal du commerçant, d'avoir
connaissance de
ce message. Ainsi, le code d'authentification de message S1 peut, en fonction
de mode de
réalisation, prendre la place des codes d'authentification traditionnellement
utilisés dans les
protocoles de paiement, et plus particulièrement dans les protocoles de
paiement mis en
oeuvre dans la cadre des spécifications EMV. On comprend, à lecture de ce qui
précède, que
les procédés mis en oeuvre tant dans le terminal du commerçant que dans le
dispositif
d'utilisateur, sont indépendants. On comprend également que le terminal du
commerçant et le
dispositif d'utilisateur sont indépendant l'un de l'autre. Dès lors, il est
possible de mettre en
CA 03029154 2018-12-21
WO 2018/002351
PCT/EP2017/066365
14
oeuvre les procédés et dispositifs décrits dans un système qui comprendra un
dispositif
d'utilisateur et un terminal de commerçant effectuant une transaction de
paiement.
5.2. Mode de réalisation
Dans ce mode de réalisation purement illustratif, la technique proposée
consiste,
notamment en une modification des signatures de Schnorr, adaptée pour deux
utilisateurs
(terminal du commerçant et dispositif d'utilisateur). La sécurité de la
technique proposée est
notamment basée sur l'hypothèse Décisionnelle Diffie-Hellman (DDH) qui est une
hypothèse
de dureté de calcul basée sur des groupes cycliques ( Decisional
Diffie¨Hellman assumption
en anglais).
Dans ce mode de réalisation, préalablement à la mise en oeuvre du protocole
d'échange sécurisé, on suppose que deux phases d'installation ont été
réalisées : une du côté
du terminal du commerçant et une du côté du dispositif de l'utilisateur.
En premier lieu, la technique proposée est mise en oeuvre en se basant sur un
groupe
G convenant à la problématique des signatures de Schnorr, avec un générateur
g.
Un groupe de Schnorr est un sous-groupe de Zpx le groupe multiplicatif des
entiers
modulos p pour un nombre premier p. Pour générer un tel groupe, on génère p,
q, et r tels que
p=qr+1, avec p et q étant des nombres premiers. Pour obtenir le générateur g
de ce groupe, on
applique la méthode suivante :
pour chaque entier h strictement supérieur à / et strictement inférieur à p:
= si hr E 1 (mo d p) alors passer à l'entier suivant ;
= sinon, la valeur g = hr (mo d p) est un générateur sous-groupe de Zpx
d'ordre
q;
Ce groupe possède une ainsi une taille donnée. La taille de ce groupe et ses
autres
paramètres sont typiquement déterminés préalablement. Dans un mode de
réalisation
particulier, la taille du groupe G est de l'ordre de 21024 (nombre 2 élevé à
la puissance 1024) :
cela signifie que la taille du nombre premier p est de l'ordre de 21024.
Dans ce mode de réalisation, le groupe G et le générateur g correspondant ont
fait
l'objet d'un paramétrage préalable, tant dans le dispositif du client que dans
le terminal du
commerçant. Ce paramétrage préalable peut avoir été fait par exemple avant
l'installation de
l'application de paiement du côté du commerçant ou de l'application de
paiement du côté du
CA 03029154 2018-12-21
WO 2018/002351
PCT/EP2017/066365
Dans d'autres modes de réalisation, ce paramétrage est réalisé lors de la
transaction
de paiement. Le terminal du commerçant et le dispositif d'utilisateur
s'entendent sur les
paramètres du groupe. Dans ce cas, compte tenu du fait que le groupe est
renégocié à chaque
transaction la taille de ce groupe peut être réduite, par exemple de moitié
(2512) ou plus (2256).
5
5.2.1. Phase d'installation du côté du dispositif de l'utilisateur
Le dispositif de l'utilisateur, qui est par exemple un terminal de
communication de
type smartphone, une tablette, est également équipé d'un SE ou d'un TEE
(agissant comme
une unité de traitement sécurisé). On rappelle que dans ce mode de
réalisation, le client
10 souhaite régler avec son dispositif. Ce dispositif dispose donc des
données nécessaires à la
réalisation d'un paiement. Il peut s'agir, dans un mode de réalisation
spécifique, de données
de carte bancaire (nom du porteur, numéro de Carte PAN, date de validité, code
de
vérification). Il peut également d'agir d'autres données, en fonction des
modes de réalisation.
Dans le cadre de la présente technique, la phase d'installation consiste ainsi
15 notamment à déposer, dans le SE ou le TEE du dispositif de l'utilisateur
(appelé également
module P), les clés privées x et y utilisée pour construire les éléments de
signatures.
Cette installation peut typiquement être mise en oeuvre par l'installation
d'une
application de paiement, comme cela est le cas de l'application de paiement
installée sur le
terminal du commerçant.
Sur la base de ce groupe G et du générateur sélectionné g:
le dispositif d'utilisateur (ou le module de preuve P) obtient ou génère une
clé privée
comprenant deux nombres entiers premiers (x,y) et, sur la base de cette clé
privée,
calcule une clé publique (X,Y), dans laquelle :
= X = gx ;
= Y = el ;
Ainsi, dans ce mode de réalisation, les deux nombres entiers premiers (x,y)
constituent
chacun une clé privée du dispositif d'utilisateur tandis que les deux nombres
entiers X et Y
constituent chacun la clé publique correspondant à ces deux clés privées.
Dans ce mode de réalisation, les deux paires de clés privées/clé publiques ont
fait
l'objet d'un paramétrage préalable dans le dispositif du client. Ce
paramétrage préalable peut
CA 03029154 2018-12-21
WO 2018/002351
PCT/EP2017/066365
16
avoir été fait par exemple avant l'installation de l'application de paiement
du côté du dispositif
d'utilisateur.
Dans d'autres modes de réalisation, la sélection de ces clés est réalisée lors
de la
transaction de paiement. Avant d'initier la transaction de paiement, le
dispositif d'utilisateur
effectue le choix de ses couples {clés privées/clés publiques}, sur la base du
groupe G et du
générateur g. Lorsque l'ensemble des paramètres est négocié au moment de la
transaction
(Groupe G, générateur g, clés publiques et privées) les tailles de ces
paramètres peuvent
avantageusement être réduites, du fait de la relative unicité des paramètres
en eux-mêmes :
ils ne sont en effet utilisés que pour une transaction, ce qui limite de
manière importante les
possibilités de fraude de la part d'un attaquant.
Une possibilité avantageuse est d'installer ces clés (et paramètres de
groupes) en
même temps qu'une application bancaire : par exemple l'application bancaire du
client. En
effet, avec le développement des applications bancaires (application qui
permettent de gérer
ses comptes depuis un smartphone o une tablette), une solution intéressante,
tant pour le
client que pour la banque, peut consister à disposer d'une application
bancaire qui permette
également de réaliser des paiements. Dans ce cas, les données nécessaires au
paiement ne
sont pas nécessairement des données de carte bancaire, mais peuvent être des
données
spécifiquement préparées par l'application bancaire de la banque, voire
spécifiquement
préparée, au moment du paiement, par l'établissement financier lui-même (c'est
à dire par un
serveur auquel l'application bancaire du client est connectée).
Pour effectuer un paiement, dans ce cas particulier, le client ouvre son
application
bancaire; sélectionne le fait qu'il souhaite effectuer un paiement; saisit un
éventuel code
confidentiel (ou s'authentifie par exemple par voie biométrique); et appose
son dispositif sur le
terminal du commerçant. L'application bancaire réagit aux requêtes du terminal
du
commerçant (comme explicité dans la présente) et le paiement est effectué.
Pour la banque,
comme pour le client, les bénéfices sont réels, tant en termes de sécurité de
la transaction
(faite par l'application bancaire), qu'en termes de fidélisation du client
(qui n'est plus obligé
d'effectuer un paiement avec une application tierce, dont il n'a pas de
garantie, par exemple
au niveau de la sécurité et de la confidentialité des données transmises et
traitées).
Pour la mise en oeuvre de cette technique, il importe que le terminal du
commerçant
ait connaissance des clés publiques X et Y : soit le dispositif d'utilisateur
fournit ces clés lors de
CA 03029154 2018-12-21
WO 2018/002351
PCT/EP2017/066365
17
la transaction, soit le terminal du commerçant est à même d'obtenir ces clés
auprès d'un tiers
de confiance. Dans ce dernier cas, selon la présente, le dispositif
d'utilisateur dispose d'un
identifiant unique (Uid), lequel est associé, auprès du tiers de confiance, au
deux clés
publiques X et Y. Lorsque le terminal du commerçant souhaite obtenir ces clés
publiques, il
transmet, au tiers de confiance, une requête d'obtention des clés en se basant
sur l'identifiant
(Uid) du dispositif d'utilisateur. Préalablement à cette transmission, le
dispositif d'utilisateur a
transmis son identifiant unique au terminal du commerçant (par exemple lors de
l'initialisation
de la transaction).
5.2.2. Phase d'installation du côté du terminal du commerçant
Sur la base de ce groupe G et du générateur sélectionné g:
le terminal du commerçant (ou le module de vérification V) obtient ou génère
une clé
privée z, (nombre premier entier aléatoire) et sur la base de cette clé
privée, calcule
une clé publique Z, telle que : Z = gz ;
Dans ce mode de réalisation, la paire de clé privée/clé publique a fait
l'objet d'un
paramétrage préalable dans le terminal du commerçant. Ce paramétrage préalable
peut avoir
été fait par exemple avant l'installation de l'application de paiement du côté
du terminal du
commerçant.
Comme précédemment, dans d'autres modes de réalisation, la sélection de ces
clés
peut être réalisée lors de la transaction de paiement.
De même, comme précédemment, le dispositif d'utilisateur prend connaissance de
la
clé publique Z du terminal du commerçant. Soit le terminal du commerçant
transmet cette clé
directement au dispositif du client, soit le dispositif du client utilise un
identifiant unique du
terminal du commerçant (Cid) pour obtenir cette clé publique auprès d'un tiers
de confiance.
Dans un mode de réalisation spécifique, la phase d'installation est réalisée
lors de
l'installation d'une application de paiement sur un terminal de communication
(de type
smartphone, tablette, ou ordinateur) du commerçant, ledit terminal de
communication étant
équipé d'un TEE et/ou d'un SE (également appelé module V). Ce mode de
réalisation présente
l'avantage de ne pas avoir à communiquer la clé privée z au terminal de
communication en
tant que tel : cette donnée n'est communiquée qu'au SE ou au TEE. Ainsi, on
assure que le
terminal de communication (et surtout les éventuelles applications frauduleuse
de ce
terminal), ne puisse pas avoir accès à cette clé privée.
CA 03029154 2018-12-21
WO 2018/002351
PCT/EP2017/066365
18
5.2.3. Déroulé de l'authentification
Dans ce mode de réalisation, l'authentification est mise en oeuvre de la
manière
suivante :
- le module P effectue une transformation du message m, sous une forme
numérique,
afin que ce message m corresponde à un élément du groupe G: pour ce faire, le
message m est transformé en binaire (représentation binaire du message m) et
la
forme binaire est utilisée pour obtenir une forme numérique, la forme
numérique
correspondant à un élément du groupe G; d'autres méthodes peuvent être
envisageables en fonctions des applications ;
- le module P sélectionne aléatoirement (ou pseudo aléatoirement) un
élément t du
groupe G;
- le module P calcule, à partir du message m, de la donnée aléatoire t et
de la fonction
de hachage H, un code d'authentification Si selon la formule suivante :
o Si = H(m l i t), ou l l est l'opérateur de concaténation ;
- le module P calcule, à partir du message m, de la donnée aléatoire t, de
la clé publique
Z, de la première clé privée x de P et du code d'authentification Si, le
premier
composant de signature 52, selon la formule suivante :
o 52 = (111 I I t)Zel
- le module P calcule, à partir du message m, de la donnée aléatoire t, de
la clé publique
Z, de la deuxième clé privée y de P et du code d'authentification Si, le
deuxième
composant de signature 53;
o 53 = (Mi I t)Zs1
- le module P transmet, au terminal du commerçant (ou au module V), le code
d'authentification Si, et les deux composants de signature 52 et 53.
Ainsi, le dispositif d'utilisateur n'a pas transmis le message m, ni même une
version
signée de celui-ci car ce dernier se trouve être concaténé avec un aléa (t),
avant d'être haché
pour produire Si. Dès lors, un attaquant, qui intercepterait par exemple le
code
d'authentification Si, ne pourrait pas, à partir de celui-ci, inférer le
contenu du message m.
Les méthodes de calcul des valeurs 51, 52 et 53 utilisent x et y (qui sont
privées et donc
connues du signataire seul, c'est-à-dire le dispositif d'utilisateur), et de Z
(qui est la clé
publique du destinataire, c'est-à-dire le terminal de paiement).
Essentiellement, 52 et 53 sont
CA 03029154 2018-12-21
WO 2018/002351
PCT/EP2017/066365
19
des quantités créées à partir de ces trois informations et du message m.
L'exponentiation
garantit la protection des clés privées, et la multiplication du message par
la quantité
exponentiée protège son contenu.
De son côté, le terminal du commerçant reçoit les données 51, 52 et 53. Sur la
base de
ces données, il va déterminer (avec un doute raisonnable), que ces données
correspondent
bien aux résultats de calculs effectués sur la base du message m.
Pour ce faire, le terminal du commerçant met en oeuvre les étapes suivantes :
- calcule, à partir du premier composant de signature 52, de la clé
publique X
(correspondant à la clé privée x), de sa propre clé privée Z, et du code
d'authentification Si, une première valeur de référence, notée Iffrii
O Utrij = S2Xzsi
- calcule, à partir du deuxième composant de signature 53, de la clé
publique Y
(correspondant à la clé privée y), de sa propre clé privée Z, et du code
d'authentification Si, une deuxième valeur de référence, notée 1.4.2] ;
0 utrzi = s3y-zsi.
- vérifie que la première valeur de référence Iffrii est égale à la
deuxième valeur de
référence 142); et, lorsque les deux valeurs sont égales :
- vérifie que la valeur H(142]) est égale à Si.
Si la valeur de H(142]) est égale à Si, alors le terminal du commerçant
dispose d'une
information d'une certitude suffisante pour estimer que le dispositif
d'utilisateur est bien en
possession du message m et que celui-ci est authentique. Dès lors, le terminal
du commerçant
peut terminer la transaction (par exemple il peut transmettre Si au système de
paiement pour
validation de la transaction).
Explicité autrement, Le terminal du commerçant effectue les calculs suivants :
0 Utrij = s2X-z5i = (m I I t)ZA(x 51) X^(-z Si) =
(m I I t)g^(z x 51) g^(- z x 51) =
(ml lt)
et
O utrzi =
= (m I I t)ZA(y 51) YA(-z 51) =
[m I I t)g^(yz 51) g^(-yz 51) =
(ml lt)
CA 03029154 2018-12-21
WO 2018/002351
PCT/EP2017/066365
Ainsi, l'authentification des données transmises, lors d'une opération de
paiement,
entre un terminal d'un commerçant et un dispositif d'utilisateur, en utilisant
une
communication en champs proche (NEC), permet de valider une transaction de
manière
5 sécuritaire.
5.3. Autres caractéristiques et avantages
On décrit, en relation avec la figure 3, un terminal de communication mis en
oeuvre
pour réaliser une authentification de données dans le cadre d'un processus de
paiement, selon
le procédé décrit préalablement.
10 Par exemple, le terminal de communication, faisant office de terminal de
paiement,
comprend une mémoire 31 comprenant notamment une mémoire tampon, une unité de
traitement général 32, équipée par exemple d'un microprocesseur, et pilotée
par un
programme d'ordinateur 33, et une unité de traitement sécurisée 34 (notée V
précédemment), pilotée par un programme d'ordinateur 35, ces unités de
traitement mettant
15 en oeuvre le procédé d'authentification tels que décrit précédemment
pour effectuer un
paiement auprès du commerçant.
A l'initialisation, les instructions de code du programme d'ordinateur 35 sont
par
exemple chargées dans une mémoire avant d'être exécutées par le processeur de
l'unité de
traitement sécurisée 34. L'unité de traitement 34 reçoit en entrée au moins un
code
20 d'authentification et deux éléments de signature. Le microprocesseur de
l'unité de traitement
sécurisée 34 met en oeuvre les étapes du procédé d'authentification, selon les
instructions du
programme d'ordinateur 35 pour fournir, à l'unité de traitement générale 32,
une donnée
représentative de validation de transaction et le cas échéant transmettre, à
un système de
traitement, une donnée de validation de transaction. L'unité de traitement
générale 32
.. effectue un traitement de ces données pour les transmettre à un dispositif
d'un client (par
exemple un smartphone, une tablette) dans le cadre d'une transaction de
paiement.
Pour cela, le terminal de communication comprend, outre la mémoire tampon 31,
des
moyens de communications, tels que des modules de communication réseau, des
moyens de
transmission de donnée et des circuits de transmission de données entre les
divers
composants du terminal de communication.
CA 03029154 2018-12-21
WO 2018/002351
PCT/EP2017/066365
21
Ces moyens peuvent se présenter sous la forme d'un processeur particulier
implémenté au sein du terminal de communication. Selon un mode de réalisation
particulier,
ce dispositif met en oeuvre une application spécifique qui est en charge de la
réalisation des
transactions, cette application étant par exemple fournie par le fabricant du
processeur en
question afin de permettre l'utilisation dudit processeur ou par un
fournisseur de solution de
paiement pour des terminaux "ouverts". Pour ce faire, le processeur comprend
des moyens
d'identification uniques. Ces moyens d'identification uniques permettent
d'assurer
l'authenticité du processeur.
Par ailleurs, le dispositif comprend en outre les moyens de communication en
champs
proches, dits NEC et des moyens de transmission et de réception de données en
provenance
de réseaux de communications. Ces moyens se présentent également comme des
interfaces
de communications permettant d'échanger des données sur des réseaux de
communication,
des moyens d'interrogations et de mise à jour de base de données.
On décrit, en relation avec la figure 4, un dispositif d'utilisateur mis en
oeuvre pour
réaliser une authentification de données dans le cadre d'un processus de
paiement, selon le
procédé décrit préalablement.
Par exemple, le dispositif d'utilisateur comprend une mémoire 41 constituée
d'une
mémoire tampon, une unité de traitement général 42, équipée par exemple d'un
microprocesseur, et pilotée par un programme d'ordinateur 43, et une unité de
traitement
sécurisée 44 (notée P, précédemment), pilotée par un programme d'ordinateur
45, ces unités
de traitement mettant en oeuvre le procédé d'authentification tels que décrit
précédemment
pour effectuer un paiement auprès du commerçant.
A l'initialisation, les instructions de code du programme d'ordinateur 45 sont
par
exemple chargées dans une mémoire avant d'être exécutées par le processeur de
l'unité de
traitement sécurisée 44. L'unité de traitement sécurisée 44 reçoit en entrée,
un message m
dont il est nécessaire de prouver la connaissance. Le microprocesseur de
l'unité de traitement
sécurisée 44 met en oeuvre les étapes du procédé d'authentification, selon les
instructions du
programme d'ordinateur 45 pour fournir, à l'unité de traitement générale 42,
au moins un
code d'authentification et deux éléments de signature à transmettre à un
terminal de
commerçant. L'unité de traitement générale 42 effectue la transmission de ces
données.
CA 03029154 2018-12-21
WO 2018/002351
PCT/EP2017/066365
22
Pour cela, le dispositif d'utilisateur comprend, outre la mémoire tampon 41,
des
moyens de communications, tels que des modules de communication réseau, des
moyens de
transmission de donnée et des circuits de transmission de données entre les
divers
composants du dispositif d'utilisateur.
Ces moyens peuvent se présenter sous la forme d'un processeur particulier
implémenté au sein du dispositif d'utilisateur. Selon un mode de réalisation
particulier, ce
dispositif met en oeuvre une application spécifique qui est en charge de la
réalisation des
transactions, cette application étant par exemple fournie par le fabricant du
processeur en
question afin de permettre l'utilisation dudit processeur ou par un
fournisseur de solution de
paiement pour des terminaux "ouverts". Pour ce faire, le processeur comprend
des moyens
d'identification uniques. Ces moyens d'identification uniques permettent
d'assurer
l'authenticité du processeur.
Par ailleurs, le dispositif comprend en outre les moyens de communication en
champs
proches, dits NEC et des moyens de transmission et de réception de données en
provenance
de réseaux de communications. Ces moyens se présentent également comme des
interfaces
de communications permettant d'échanger des données sur des réseaux de
communication,
des moyens d'interrogations et de mise à jour de base de données.
