WO2016034812A1 - Sécurisation de clés de cryptage pour transaction sur un dispositif dépourvu de module sécurisé - Google Patents

Sécurisation de clés de cryptage pour transaction sur un dispositif dépourvu de module sécurisé Download PDF

Info

Publication number
WO2016034812A1
WO2016034812A1 PCT/FR2015/052316 FR2015052316W WO2016034812A1 WO 2016034812 A1 WO2016034812 A1 WO 2016034812A1 FR 2015052316 W FR2015052316 W FR 2015052316W WO 2016034812 A1 WO2016034812 A1 WO 2016034812A1
Authority
WO
WIPO (PCT)
Prior art keywords
encryption key
mobile device
key
personal data
cryptogram
Prior art date
Application number
PCT/FR2015/052316
Other languages
English (en)
Inventor
Eric LASSOUAOUI
Francis LIMOUSY
Original Assignee
Oberthur Technologies
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from FR1458191 external-priority
Application filed by Oberthur Technologies filed Critical Oberthur Technologies
Publication of WO2016034812A1 publication Critical patent/WO2016034812A1/fr

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3227Aspects of commerce using mobile devices [M-devices] using secure elements embedded in M-devices
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/325Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327Short range or proximity payments by means of M-devices
    • G06Q20/3278RFID or NFC payments by means of M-devices
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3823Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829Payment protocols; Details thereof insuring higher security of transaction involving key management
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401Transaction verification
    • G06Q20/4012Verifying personal identification numbers [PIN]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/06Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/06Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/068Network architectures or network communication protocols for network security for supporting key management in a packet data network using time-dependent keys, e.g. periodically changing keys
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041Key generation or derivation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload

Abstract

L'invention concerne la sécurisation de clés de cryptage utilisées lors de transactions lorsque le dispositif utilisateur est dépourvu de module sécurisé. Sur le dispositif, sont réalisés des étapes d'encryptage d'un message avec une clé de cryptage et d'envoi du cryptogramme obtenu à un serveur distant de transaction. La clé de cryptage a une durée de vie limitée. Lorsque la clé de cryptage courante est périmée, le dispositif reçoit, d'un serveur distant sécurisé équipé d'un module sécurisé, une nouvelle clé de cryptage encryptée (310); reçoit une donnée personnelle saisie par un utilisateur sur une interface de saisie (312); décrypte la nouvelle clé de cryptage à l'aide de la donnée personnelle saisie (314); et supprime la donnée personnelle de ses mémoires (316) avant d'utiliser ladite nouvelle clé de cryptage pour obtenir le cryptogramme à envoyer au serveur distant de transaction.

Description

SECURISATION DE CLES DE CRYPTAGE POUR TRANSACTION SUR UN DISPOSITIF
DEPOURVU DE MODULE SECURISE
DOMAINE DE L'INVENTION
La présente invention concerne de façon générale le domaine de la cryptographie, et plus particulièrement celui de la sécurisation de clés de cryptage, utilisées par exemple lors de transactions. La présente invention vise notamment un procédé et un dispositif de traitement cryptographique mettant en oeuvre une sécurisation accrue d'une clé de cryptage.
CONTEXTE DE L'INVENTION
Dans le domaine des communications numériques, il existe un grand nombre d'applications qui font appel à des services cryptographiques sécurisés. C'est par exemple le cas des transactions informatiques telles que les transactions financières mises en oeuvre par des applications de paiement.
De telles applications de paiement, comme par exemple les applications conformes au standard international de sécurité EMV (Europay, Mastercard, Visa), sont classiquement prévues dans des cartes à puce fortement sécurisées. Ces cartes à puce sont introduites dans un lecteur ou « terminal de paiement » ou POS (pour « Point Of Sale ») aux fins de procéder à la transaction financière. En variante, les puces peuvent être munies de moyens de communication sans fil permettant la transaction financière sans insertion dans un lecteur. Enfin, elles peuvent également être embarquées par un terminal utilisateur, tel un téléphone, opérant comme lecteur de la carte à puce pour la transaction.
Ces puces, également dénommés élément sécurisé (SE pour « Secure Elément ») ou élément de sécurité matériel (HSE pour « Hardware Security Elément »), sont particulièrement bien adaptées à la protection des clés cryptographiques. La majorité des mesures de sécurité visant à protéger ces clés est mise en oeuvre au niveau matériel de la carte.
De tels éléments sécurisés ne sont pas toujours disponibles. Par ailleurs, pour des raisons de coût, il peut également être souhaitable de ne pas avoir à diffuser de telles puces à un nombre important d'utilisateurs. Il peut aussi être souhaitable de limiter la dépendance des transactions à la détention physique de telles puces, afin que ces transactions se révèlent être plus souples pour les utilisateurs.
Ainsi, il est apparu un intérêt à prévoir des applications de transaction reposant sur des services cryptographiques au sein même de plateformes matérielles dépourvues de mesures sécuritaires, et par conséquent de tels éléments sécurisés.
Dans la publication US 2003/054,474, une application de paiement est mise en oeuvre dans un dispositif mobile utilisateur sans toutefois détenir la clé cryptographique nécessaire à la réalisation d'une transaction de paiement. Cette clé est détenue par un élément sécurisé distant auquel un serveur d'authentification et de transaction accède. En pratique, cet élément sécurisé distant utilise la clé cryptographique qu'il détient afin de calculer un cryptogramme attendu pour une transaction donnée et le communique au dispositif mobile. Ainsi ce dernier peut transmettre le cryptogramme au terminal de paiement de sorte que la transaction de paiement soit autorisée.
Toutefois ce mode de fonctionnement repose sur un appel de procédure à distance pour récupérer le cryptogramme attendu, qui peut s'avérer particulièrement coûteux en temps. Dans la publication susvisée en lien avec les figures 15 et 16, une latence de 200 millisecondes est évoquée, ce qui semble toutefois constituer une estimation optimise. Or une latence de cet ordre de grandeur ou plus longue peut s'avérer préjudiciable à la réalisation de transactions car, pour des raisons de sécurité, celles-ci sont généralement configurées pour s'interrompre en cas d'attente trop longue.
RESUME DE L'INVENTION
L'invention concerne donc un procédé de traitement cryptographique, comprenant, sur un dispositif mobile, type téléphone mobile, carte à puce non sécurisée, etc., une étape d'obtention d'une clé de cryptage, une étape d'encryptage d'un message, par exemple un message de transaction financière, à l'aide de la clé de cryptage obtenue pour obtenir un cryptogramme et une étape d'envoi du cryptogramme, qui inclut par exemple les informations relatives à la transaction, à un serveur distant de transaction.
La présente invention vise à résoudre tout ou partie des inconvénients relevés dans les techniques de l'art antérieur.
A cet effet, selon l'invention, ladite clé de cryptage a une durée de vie limitée, par exemple pour une transaction ou une session de communication, impliquant de la sorte un renouvellement fréquent de cette clé de cryptage. Une telle clé s'apparente ainsi à une « clé de session » pour sa durée de vie éphémère.
En outre, l'étape d'obtention de la clé de cryptage par le dispositif mobile inclut les étapes suivantes, lorsqu'une précédente clé de cryptage obtenue par le dispositif mobile est périmée (c'est-à-dire que la durée de vie de la clé a expiré) :
recevoir, d'un serveur distant sécurisé, une nouvelle clé de cryptage encryptée, saisir une donnée personnelle sur une interface de saisie connectée au dispositif mobile, par exemple via une interface d'un terminal de paiement ou via le clavier d'un téléphone mobile formant ou hébergeant le dispositif mobile,
décrypter la nouvelle clé de cryptage reçue à l'aide de la donnée personnelle saisie, et supprimer la donnée personnelle saisie du dispositif mobile avant d'utiliser ladite nouvelle clé de cryptage décryptée pour encrypter le message et obtenir le cryptogramme. Ainsi la donnée personnelle n'est que temporaire sur le dispositif mobile.
Comme dans la publication susmentionnée, le procédé selon l'invention permet de sécuriser l'accès et le stockage des clés de transaction générées alors même que le dispositif mobile est dépourvu de mécanismes de sécurité. En effet, les clés générées à raison de leurs péremptions sont détenues par un serveur distant sécurisé.
En outre, la présente invention permet de réduire les risques d'échec d'une transaction en s'affranchissant du calcul du cryptogramme par le serveur distant sécurisé et des échanges d'informations entre le dispositif mobile et ce serveur aux fins de ce calcul, tout en conservant un fort niveau de sécurité. Ainsi, la latence d'au moins 200 millisecondes évoquée dans la publication susvisée est largement réduite.
Cette situation avantageuse et sécurisée est rendue possible par l'invention grâce à la transmission de la nouvelle clé de cryptage à utiliser et à sa protection par des données personnelles temporaires, c'est-à-dire récupérées uniquement pour accéder à cette clé de cryptage. En effet, l'utilisation de ces données personnelles temporaires assure une sécurité forte de la clé de cryptage transmise car elles ne sont pas stockées à demeure sur le dispositif mobile.
Corrélativement, l'invention concerne également un dispositif mobile, type téléphone mobile, carte à puce non sécurisée, etc., comprenant un module d'obtention d'une clé de cryptage, un module cryptographique configuré pour encrypter un message, par exemple un message de transaction financière, à l'aide de la clé de cryptage obtenue afin d'obtenir un cryptogramme et un module de communication configuré pour envoyer le cryptogramme, qui inclut par exemple les informations relatives à la transaction, à un serveur distant de transaction.
Selon l'invention, ladite clé de cryptage a une durée de vie limitée.
Selon l'invention toujours, le module d'obtention de la clé de cryptage est configuré pour, lorsqu'une précédente clé de cryptage obtenue par le dispositif mobile est périmée :
recevoir, d'un serveur distant sécurisé, une nouvelle clé de cryptage encryptée, obtenir une donnée personnelle saisie par un utilisateur sur une interface de saisie connectée au dispositif mobile, par exemple via une interface d'un terminal de paiement ou via le clavier d'un téléphone mobile formant ou hébergeant le dispositif mobile,
décrypter la nouvelle clé de cryptage reçue à l'aide de la donnée personnelle saisie, et supprimer la donnée personnelle saisie du dispositif mobile avant d'utiliser ladite nouvelle clé de cryptage décryptée pour encrypter le message et obtenir le cryptogramme.
L'invention a également pour objet un produit programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté sur un ordinateur.
Le dispositif mobile et le produit programme d'ordinateur selon l'invention présentent des avantages similaires à ceux exposés précédemment en lien avec le procédé.
D'autres caractéristiques du procédé et du dispositif mobile selon des modes de réalisation sont décrites dans les revendications dépendantes, et résumées ci-après en termes de procédés. Le procédé de traitement cryptographique peut constituer une partie d'un procédé de communication dont un exemple est décrit en détail par la suite. De même le dispositif mobile fait partie d'un système comme décrit pas la suite.
Selon des modes de réalisation, la donnée personnelle est un code PIN saisi par un utilisateur. Cette configuration permet de conserver l'interaction classique de l'utilisateur, sans nécessiter la saisie de nouvelles données aux fins de l'invention.
Selon d'autres modes de réalisation, une clé de décryptage pour décrypter la clé de cryptage encryptée est formée à partir de la donnée personnelle saisie et d'une donnée commune au dispositif mobile et au serveur sécurisé distant. Cette configuration améliore la sécurité de la clé de cryptage fournie, de façon encryptée par le serveur sécurisé distant.
Selon d'autres modes de réalisation, le procédé comprend la transmission de la nouvelle clé de cryptage depuis le serveur distant sécurisé vers le serveur distant de transaction. Cette disposition permet à ce dernier serveur de pouvoir valider le cryptogramme reçu du dispositif mobile.
Selon d'autres modes de réalisation,, ladite clé de cryptage est sélectionnée parmi une liste chaînée ou série de clés générées à partir d'une clé racine et d'une fonction à sens unique appliquée à la clé précédemment générée, c'est-à-dire que la génération des clés est récursive. Ladite sélection est en outre réalisée selon l'ordre inverse de génération des clés, signifiant que la dernière clé générée est utilisée en premier, et la première clé générée en dernier. Cela permet un renouvellement sécurisé des clés.
Selon encore d'autres modes de réalisation, le cryptogramme comprend des informations relatives à une transaction informatique, par exemple relatives à une transaction financière, telles qu'un montant. Une transaction informatique, telle qu'une réservation, un achat ou un paiement, consiste notamment en la mise en oeuvre d'une suite atomique, cohérente, isolée et durable d'opérations qui font passer une base de données des transactions d'un état A, antérieur à la transaction, à un état B postérieur à celle-ci.
Selon encore d'autres modes de réalisation, la clé de cryptage est renouvelée après un nombre fixé de générations de cryptogramme, c'est-à-dire après un nombre fixé de transactions utilisant cette clé, par exemple à chaque nouvelle transaction informatique. Cette disposition permet de garantir un renouvellement régulier des clés de cryptage.
Selon encore d'autres modes de réalisation, le décryptage de la clé de cryptage reçue met en oeuvre un algorithme cryptographique à clé symétrique. Cette disposition permet un traitement rapide à la fois du cryptage de cette clé par le serveur distant et du décryptage de celle-ci par le dispositif mobile. Ainsi la latence introduite par les traitements selon l'invention est minimisée. BREVE DESCRIPTION DES FIGURES
D'autres avantages, buts et caractéristiques particulières de la présente invention ressortiront de la description qui va suivre faite, dans un but explicatif et nullement limitatif, en regard des dessins annexés, dans lesquels :
la figure 1 représente schématiquement une infrastructure dans laquelle des modes de réalisation de la présente invention sont mis en oeuvre ;
la figure 2 illustre un exemple d'architecture matérielle pour les équipements représentés sur la figure 1 ;
les figures 3a, 3b et 3c illustrent, sous forme d'ordinogrammes, des étapes générales de procédés pour une mise en oeuvre de l'invention, respectivement au niveau du dispositif mobile, du serveur d'authentification et du serveur sécurisé distant de la figure 1 ; et
la figure 4 illustre les échanges de messages entre les équipements de la figure 1 lors d'une mise en oeuvre de l'invention. DESCRIPTION DETAILLEE DE L'INVENTION
La figure 1 illustre un exemple d'infrastructure dans laquelle la présente invention peut être mise en oeuvre. Cette infrastructure peut être similaire à celle décrite dans la publication US 2013/054,474 susmentionnée.
L'infrastructure 1 comporte un dispositif mobile 10, un point de vente POS 12 officiant comme lecteur du dispositif mobile 10, un ou plusieurs réseaux de communication 14, un serveur d'authentification d'utilisateur 16, un serveur de transaction 17 et un serveur sécurisé distant 18. Bien qu'un seul dispositif mobile 10 soit représenté, une pluralité de dispositifs mobiles 1 0 détenus par une pluralité d'utilisateurs respectifs est largement envisagée pour réaliser de façon concomitante ou non une ou plusieurs transactions nécessitant la mise en oeuvre de l'invention.
Le dispositif mobile 10 peut être tout type d'équipement utilisateur doté d'une mémoire et de moyens de traitement, type CPU, pour mémoriser et exécuter une application requérant un service cryptographique sécurisé. Il s'agit par exemple d'une application de paiement nécessitant l'utilisation d'une clé pour chiffrer ou encrypter les informations relatives à la transaction financière.
A titre d'exemple, le dispositif mobile peut être un téléphone portable, un module de traitement type carte à puce non sécurisée.
Le dispositif mobile 1 0 comporte notamment des moyens de communication sans fil conforme à la norme ISO/IEC 14443, afin de communiquer avec le lecteur 12. A cette fin, le dispositif mobile peut mettre en oeuvre le protocole NFC. En variante, des moyens de communication par contact type ISO/IEC 7816 ou filaire (USB) peuvent être envisagés.
Le dispositif mobile 10 peut également comprendre des moyens de communication avec le serveur d'authentification 16 par l'intermédiaire d'un réseau de communication 14, type réseau étendu tel que le réseau de téléphonie mobile ou le réseau Internet. La figure 2 représente un exemple d'architecture matérielle pour un équipement tel le dispositif mobile 1 0.
L'équipement comprend un bus de communication 2 auquel sont reliées :
- une unité de traitement 20 -ou microprocesseur- notée CPU (pour Central Processing Unit) ;
- une ou plusieurs mémoires non volatile 22 par exemple ROM (pour Read Only Memory), EEPROM (pour de Electrically Erasable Read Only Memory) ou encore Flash, stockant par exemple l'application de paiement;
- une mémoire vive 24 ou mémoire cache ou mémoire volatile par exemple RAM (pour Random Access Memory) ; et
- une interface de communication 26 adaptée à transmettre et à recevoir des données, par exemple via un réseau de télécommunications ou une interface de lecture/écriture.
Optionnellement, l'équipement peut comprendre une interface d'entrées/sorties I/O (pour Input/Output), par exemple un écran, un clavier, une souris ou un autre dispositif de pointage tel qu'un écran tactile ou une télécommande ; cette interface I/O permet à un utilisateur d'interagir avec le système au cours de la mise en oeuvre du procédé via une interface graphique, notamment de saisir un code PIN comme décrit par la suite.
La mémoire vive 24 comprend des registres adaptés à l'enregistrement des variables et paramètres créés et modifiés au cours de l'exécution d'un programme informatique comprenant des instructions pour la mise en oeuvre d'étapes d'un procédé selon l'invention lors de sa mise en oeuvre. Les codes d'instructions du programme stocké en mémoire non-volatile sont chargés en mémoire RAM en vue d'être exécutés par l'unité de traitement CPU.
Le bus de communication permet la communication et l'interopérabilité entre les différents éléments représentés sur la figure 2. La représentation du bus n'est pas limitative et, notamment, l'unité de traitement est susceptible de communiquer des instructions à tout élément de l'équipement représenté, directement ou par l'intermédiaire d'un autre élément de celui-ci.
De retour à la figure 1 , le point de vente POS 12 peut être tout type de terminal de paiement classique, doté d'un lecteur apte à communiquer avec le dispositif mobile 10.
La lecture peut être de type RFID ou selon la norme ISO/IEC 14443, voire avec contact.
Le point de vente POS 12 est également doté de moyens de communication sur le réseau 14 afin de communiquer avec le serveur de transaction 17 (qui peut être commun avec le serveur d'authentification 16). Le serveur de transaction 17 est classique. Bien entendu, une pluralité de serveurs peut être prévue pour réaliser l'ensemble des fonctions exposées par la suite.
Le terminal de paiement 12 peut avoir l'architecture matérielle représentée sur la figure 2, équipée en outre d'un lecteur comme exposé ci-dessus. Le serveur d'authentification et de transaction 1 6 est relié au réseau de communication 14 aux fins d'établir une connexion sécurisée avec le dispositif mobile 10 pour la réalisation d'une transaction. En outre, le serveur 16 dispose d'une connexion, soit directe, soit via un réseau étendu tel le réseau 14, au serveur sécurisé distant 18 afin d'obtenir une clé de cryptage à jour comme expliqué par la suite. A titre d'exemple de connexion directe, le serveur sécurisé 18 peut être un serveur web hébergé dans le serveur d'authentification 1 6.
Le serveur 16 peut être conforme à l'architecture matérielle représentée sur la figure
2.
Le serveur sécurisé distant 1 8 comprend par exemple un module sécurisé SE stockant une liste chaînée de clés de cryptage pour le dispositif mobile 10. En variante, le serveur sécurisé distant 18 est mis en oeuvre dans un tel module sécurisé SE, par exemple un serveur dans une carte à puce. Dans cette variante, la carte à puce peut être installée dans le serveur 16 et communiquer par des unités APDU selon le protocole ISO 7816. Dans la suite de la description on fera référence principalement à un « module sécurisé » 18.
En particulier, le module sécurisé distant 1 8 stocke en mémoire une clé maître MK pour chaque application de transaction (par exemple de paiement) mise en oeuvre par un dispositif mobile 10. La clé maître MK est utilisée comme point de départ d'un processus de génération d'une liste de clés de transaction ou « clés de session », utilisées par les dispositifs mobiles 10 pour crypter les informations de transaction en cryptogramme. Cette génération est également connue sous l'appellation de diversification ou dérivation de clés.
La génération de la série de clés est effectuée à l'aide d'une fonction f à sens unique appliquée récursivement à MK puis à chaque clé SKn générée :
SK, = f(MK)
Figure imgf000009_0001
Le nombre n d'itérations est prédéfini, par exemple n=1024.
Ainsi la liste de clés de cryptage obtenue est chaînée {SK^ SK2, SKn}.
En raison de la nature de la fonction f, les clés sont mises à disposition du dispositif mobile 10 dans l'ordre inverse de la liste chaînée, c'est-à-dire dans l'ordre n, n-1 , n-2, 2, 1 . Ainsi, si une clé SK, est volée, elle ne peut être utile qu'à la détermination des clés d'indice supérieur, c'est-à-dire des clés déjà répudiées.
La clé maître MK n'est jamais transmise et peut être réutilisée pour produire une nouvelle liste chaînée, par exemple en utilisant une autre fonction à sens unique (ayant par exemple un paramétrage différent).
Dans une variante évitant de stocker la liste chaînée, SK, peut être obtenue directement par une fonction f(SK, i).
Afin de garantir une forte sécurité des transactions, chaque clé de cryptage ainsi générée a une durée de vie limitée dans le temps à compter de sa mise en circulation, c'est-à- dire dès lors qu'elle est mise à disposition par le module sécurisé distant. La clé de cryptage qui est en cours d'utilisation est dite « clé courante ». A titre d'exemple, la durée de vie limitée peut être définie par une fréquence de renouvellement de la clé courante. Par exemple, chaque dimanche à minuit la clé courante SKj devient obsolète et est remplacée par la nouvelle clé courante SKj.! .
Dans un autre exemple, cette durée de vie limitée peut être définie au regard d'un nombre de transactions utilisant la clé courante. Par exemple, la clé de cryptage peut être renouvelée toutes les /( transactions. A titre d'exemple, k=10.
Ce mécanisme de regénération régulière de la clé courante de cryptage utilisée pour les transactions permet de réduire les risques associés à la compromission de la clé de cryptage. En outre, le fait que la clé de cryptage courante soit transmise au dispositif mobile rend possible que le cryptogramme pour la transaction soit calculé par le dispositif mobile directement à partir de cette clé de cryptage désormais détenue localement.
Afin de protéger la clé de cryptage courante, l'invention prévoit que le module sécurisé distant communique la nouvelle clé de cryptage sous forme encryptée à l'aide d'une clé formée à partir d'une donnée personnelle fournie par l'utilisateur.
Ainsi, le module sécurisé distant 18 comporte également des moyens cryptographiques permettant d'encrypter des données, et notamment d'encrypter les clés SK, à l'aide d'un algorithme cryptographique à clé symétrique, par exemple l'algorithme triple DES (3DES) : enc3des(SK KSYM) où enc3des est la fonction d'encryptage basée sur le Triple DES.
La clé symétrique KSYM utilisée peut être générée à la volée à partir de la donnée personnelle de l'utilisateur, lorsqu'une nouvelle clé SK, doit être communiquée. La donnée personnelle de l'utilisateur est sauvegardée en mémoire du module sécurisée distant pour être utilisée dans la formation de la clé symétrique. Cette donnée personnelle peut être saisie par l'utilisateur lors d'une procédure d'inscription ou d'installation de l'application de paiement, permettant par exemple d'associer cette donnée personnelle à la clé maître MK correspondant à l'application installée.
En variante, les clés SK, sont toutes encryptées à l'avance et stockées comme telles dans le module sécurisé.
La donnée personnelle de l'utilisateur est préférentiellement une information que l'utilisateur connaît bien, telle qu'un code PIN. En particulier, il peut s'agir du même code PIN que celui utilisé dans une procédure d'authentification auprès du serveur 16.
En variante, il peut s'agir d'un mot de passe, ou d'un mot de passe étendu (« passphrase » selon la terminologie anglo-saxonne).
Dans un mode de réalisation, la clé symétrique est la donnée personnelle de l'utilisateur. En variante, la clé symétrique est distincte de la donnée personnelle mais calculée à partir de celle-ci, éventuellement uniquement à partir de celle-ci, par exemple à partir d'une fonction de hachage SHA-256(PIN).
Dans un autre mode de réalisation, la clé symétrique est formée à partir de la donnée personnelle de l'utilisateur et d'une donnée commune au dispositif mobile et au module sécurisé distant 18, par exemple un numéro unique d'identification de l'application de paiement considérée.
Par exemple, la clé symétrique peut résulter d'un calcul cryptographique sur ces deux données au moins, par exemple AES (donnée commune, PIN) où les données communes sont utilisées comme clé pour crypter la donnée personnelle (vice et versa).
Dans une variante, on peut appliquer une fonction de hachage sur la concaténation (« | ») de ces deux données : SHA-256(donnée commune|donnée personnelle).
Dans ces modes de réalisation utilisant la donnée commune, la clé symétrique est d'une plus grande longueur et donc offre un encryptage plus robuste.
La figure 3 illustre, sous forme d'ordinogrammes, des étapes générales de procédés au niveau du dispositif mobile (figure 3a), du serveur d'authentification (figure 3b) et du serveur sécurisé distant (figure 3c) pour une mise en oeuvre de l'invention. Ces étapes sont décrites ci-dessous à l'aide d'un exemple de diagramme temporel de séquence représenté sur la figure 4.
A l'étape 302, le dispositif mobile 1 0 est en attente d'une demande de transaction par l'utilisateur, par exemple du lancement d'une application de paiement par l'utilisateur ou en variante d'une indication par l'utilisateur d'un souhait de transaction au sein de cette application.
L'ensemble des étapes qui suivent du dispositif mobile 10 peuvent être mises en oeuvre par l'application de transaction elle-même, notamment l'application de paiement susvisée.
Lorsqu'une telle demande est reçue, l'utilisateur est invité à saisie un code d'authentification (code PIN ou mot de passe) lors de l'étape 304 permettant au dispositif mobile 10 de réaliser, si le code saisi est bon, une procédure d'authentification (étape 306) auprès du serveur 16. La procédure d'authentification peut mettre en oeuvre un échange de type « challenge/response » (stimulation/réponse) largement connu.
A noter que cette connexion avec le serveur d'authentification 16 peut être initiée par l'utilisateur avant de recevoir une demande de transaction (par exemple avant d'exécuter l'application de paiement).
Par exemple, l'authentification peut être menée lors du démarrage du dispositif mobile 10 par l'utilisateur (par exemple son téléphone mobile). Dans ce cas, le code d'authentification peut être le code PIN demandé au démarrage du terminal mobile 1 0.
En référence à la figure 3b, le serveur d'authentification 16 est en attente d'une demande d'authentification (test 340). Lorsqu'une telle demande est reçue, il traite la demande de façon classique (étape 342), par exemple en mettant en oeuvre une procédure de type « challenge/response » avec l'émetteur de la demande. Ce traitement de l'étape 342 conduit à rémission d'un message OK en cas d'authentification réussie ou d'un message NOK en cas d'échec d'authentification.
Ces étapes d'authentification sont schématiquement représentées par les flèches 402 et 404 sur la figure 4. En cas d'échec d'authentification (test 344), le serveur 16 se remet en attente d'une nouvelle demande d'authentification (étape 340).
En cas d'authentification réussie (test 344), le serveur d'authentification 16 vérifie si la clé de cryptage courante SK, pour le dispositif mobile 10 est valide ou périmée (ou obsolète) en se basant sur des règles d'obsolescence (test 346). L'obsolescence de la clé SK, peut résulter d'une durée expirée depuis l'émission de cette clé, d'une date d'expiration ou encore d'un nombre de transactions déjà réalisées à l'aide de cette clé comme décrit précédemment pour la durée de vie des clés.
A noter que le serveur d'authentification dispose en mémoire d'une table mémorisant un état de la clé courante ou des clés courantes associées à chaque dispositif mobile 1 0. Ainsi à l'aide de la procédure d'authentification identifiant le dispositif mobile, le serveur d'authentification 16 est capable de récupérer, de cette mémoire, la ou les clés courantes. Si nécessaire, le dispositif mobile 10 peut indiquer dans sa demande d'authentification (étape 306) l'application mise en oeuvre, de sorte à permettre au serveur 16 d'identifier la clé de cryptage associée à la transaction souhaitée.
Si la clé SK, n'est pas obsolète, le serveur 1 6 retourne à l'étape 340 en attente d'une nouvelle demande d'authentification.
Si la clé SK, s'avère être périmée (ou si aucune clé n'a encore été communiquée), le serveur d'authentification 16 sollicite le module sécurisé 18 pour l'obtention d'une nouvelle clé de transaction. Il peut s'agir d'un appel à une fonction du module sécurisé hébergé sur le module sécurisé 18. C'est l'étape 348 à l'issue de laquelle le serveur 16 obtient cette nouvelle clé, sous forme encryptée EKi+1 , comme décrit ci-après. Elle est représentée par les flèches 406 (demande d'une nouvelle clé), 408 (encodage de la clé) et 410 (réception de la clé) sur la figure 4.
En référence à la figure 3c, le module sécurisé du module sécurisé 18 a été configuré lors d'une étape d'initialisation 360 au cours de laquelle une liste chaînée de clés de cryptage {SK SK2, SKn} a été générée à partir d'une clé maître MK, et ce pour chaque application nécessitant une clé de cryptage et pour chaque dispositif mobile 10.
A l'étape 362, la variable / désignant la prochaine clé à communiquer est initialisée à n, n étant le nombre de clés générées à partir de MK.
Le module sécurisé 18 est ainsi en attente d'une demande de renouvellement de clé (test 364) lorsque la demande émise par le serveur 16 à l'étape 348 est reçue.
Le module sécurisé 18 traite ainsi cette demande par une étape 366 où il récupère SKj, puis une étape 368 où il encrypte SKj à l'aide de la clé symétrique KSYM évoquée plus haut (étape illustrée par la flèche 408 sur la figure 4 : EKj = enc(SKj, KSYM)), puis une étape 370 où il retourne la clé encryptée correspondante EKj au serveur 16 et transmet la clé SK correspondante au(x) serveur(s) de transaction 17 (éventuellement dans une forme encryptée convenue avec ce serveur 17). Dans l'exemple des figures 3, la clé symétrique est basée sur une donnée personnelle de l'utilisateur de type code PIN ou mot de passe. Puis l'étape 372 est exécutée pour décrémenter la variable j. Grâce à cette étape 372, la variable y vaut i-1 où /' est l'indice de la clé courante.
De plus en partant de j=n et en décrémentant j à chaque renouvellement de clé, le procédé permet de sélectionner successivement les clés SK de la liste chaînée, dans l'ordre inverse de leur génération.
Suite à l'étape 372, le module sécurisé 18 se remet en attente d'une demande de renouvellement de clé (étape 364).
De retour à la figure 3b, à réception de la clé encryptée EKj, c'est-à-dire la version encryptée de la nouvelle clé courante SK,, le serveur 1 6 la transmet au dispositif mobile 10 à l'étape 350 (flèche 412 sur la figure 4), avant de se remettre en attente d'une nouvelle demande d'authentification (étape 340).
De retour à la figure 3a relative au dispositif mobile 10, en cas d'échec d'authentification (test 308), il est vérifié si trois essais de code PIN ont été effectués (test 320) auquel cas une action de protection est réalisée (étape 322, par exemple une désactivation, temporaire ou définitive, du dispositif mobile). S'il reste des essais, le processus retourne à l'étape 304.
En cas d'authentification réussie, le dispositif mobile 10 peut recevoir, du module sécurisé 18 via le serveur 1 6, une nouvelle clé de cryptage encryptée EK, si la clé courante est périmée. Il s'agit de l'étape optionnelle 310.
Puis à l'étape 312, l'utilisateur saisit une donnée personnelle, typiquement un code
PIN ou mot de passe, sur une interface de saisie connectée au dispositif mobile 10, par exemple le clavier d'un terminal mobile. Cette étape est représentée par la flèche 414 de la figure 4.
Par exemple, l'application de paiement peut afficher une fenêtre de saisie d'une telle donnée afin d'autoriser ou valider le paiement.
Cette étape 312 est optionnelle dans le cas où la donnée personnelle nécessaire ici est le code PIN ou mot de passe déjà saisi à l'étape 304, auquel cas la donnée personnelle saisie peut être réutilisée pour le décryptage de EK,. En outre, elle n'est pas réalisée si aucune clé encryptée EK, n'est à décrypter. C'est par exemple le cas lorsque que la clé encryptée EK, a été décryptée lors d'une itération précédente et que le dispositif mobile 1 0 stocke la clé courante SK, toujours valide dans sa forme décryptée.
Puis à l'étape 314 (flèche 416 sur la figure 4), la clé de cryptage encryptée EK, est décryptée à l'aide de la donnée personnelle saisie, ici le code PIN ou mot de passe, pour obtenir la clé de cryptage courante SK, : SK, = dec(EK,, KSYM)- En effet la donnée personnelle saisie permet de former la clé symétrique KSYM nécessaire à ce décryptage.
A noter que la clé ainsi obtenue SK, peut être stockée en mémoire non volatile du dispositif mobile, auquel cas la clé encryptée EK, peut être supprimée. Dans ce cas et si la clé SK, peut être réutilisée pour des transactions ultérieures, l'étape 314 s'avère optionnelle pour les nouvelles itérations du procédé lorsque la clé n'est pas renouvelée. Dans une variante sécuritaire, seule la clé EK, est sauvegarde dans le dispositif mobile 10 et est décryptée uniquement lors d'une transaction (et la valeur décryptée SK est donc effacée à la fin de la transaction - fin des étapes 318 et 428 décrites ci-dessous).
A l'étape 316, la donnée personnelle, code PIN ou mot de passe, saisie pour décrypter la clé EK, est supprimée de toute mémoire du dispositif mobile 1 0. Il s'agit de la flèche 418 sur la figure 4.
Puis uniquement après cette suppression (qui peut être largement décorrélée dans le temps), l'étape E318 consiste à effectuer la transaction souhaitée par l'utilisateur, par exemple un paiement.
Sur la figure 4, cette transaction de type paiement se compose par exemple d'une action (flèche 420) au cours de laquelle l'utilisateur présente son dispositif mobile 10 au terminal de paiement POS 12 afin d'effectuer la transaction de paiement, laquelle étape déclenche une échange de messages conformes à EMV entre ces deux entités (flèche 422, flèche 426, et flèche 432 terminant la transaction) et un serveur de transaction 1 7 (flèches 428 et 430). Pour la réalisation de la transaction, le dispositif mobile utilise ladite clé de cryptage décryptée SK, pour encrypter des informations de transaction et obtenir un cryptogramme (flèche 424) à communiquer au serveur de transaction 17 éventuellement via le POS 12.
Les exemples qui précèdent ne sont que des modes de réalisation de l'invention qui ne s'y limite pas.

Claims

REVENDICATIONS
1. Procédé de traitement cryptographique, comprenant, sur un dispositif mobile, une étape d'obtention d'une clé de cryptage, une étape d'encryptage d'un message à l'aide de la clé de cryptage obtenue pour obtenir un cryptogramme et une étape d'envoi du cryptogramme à un serveur distant de transaction,
caractérisé en ce que ladite clé de cryptage a une durée de vie limitée ; et l'étape d'obtention de la clé de cryptage par le dispositif mobile inclut les étapes suivantes, lorsqu'une précédente clé de cryptage obtenue par le dispositif mobile est périmée :
recevoir, d'un serveur distant sécurisé, une nouvelle clé de cryptage encryptée, saisir une donnée personnelle sur une interface de saisie connectée au dispositif mobile,
décrypter la nouvelle clé de cryptage reçue à l'aide de la donnée personnelle saisie, et
supprimer la donnée personnelle saisie du dispositif mobile avant d'utiliser ladite nouvelle clé de cryptage décryptée pour encrypter le message et obtenir le cryptogramme.
2. Procédé selon la revendication 1 , dans lequel la donnée personnelle est un code PIN saisi par un utilisateur.
3. Procédé selon la revendication 1 ou 2, dans lequel une clé de décryptage pour décrypter la clé de cryptage encryptée est formée à partir de la donnée personnelle saisie et d'une donnée commune au dispositif mobile et au serveur sécurisé distant.
4. Procédé selon l'une des revendications précédentes, comprenant la transmission de la nouvelle clé de cryptage depuis le serveur distant sécurisé vers le serveur distant de transaction.
5. Procédé selon l'une des revendications précédentes, dans lequel ladite clé de cryptage est sélectionnée parmi une série de clés générées à partir d'une clé racine et d'une fonction à sens unique appliquée à la clé précédemment générée, ladite sélection étant réalisée selon l'ordre inverse de génération des clés.
6. Procédé selon l'une des revendications précédentes, dans lequel le cryptogramme comprend des informations relatives à une transaction informatique.
7. Procédé selon l'une des revendications précédentes, dans lequel la clé de cryptage est renouvelée après un nombre fixé de générations de cryptogramme.
8. Procédé selon l'une des revendications précédentes, dans lequel le décryptage de la clé de cryptage reçue met en oeuvre un algorithme cryptographique à clé symétrique.
9. Dispositif mobile comprenant un module d'obtention d'une clé de cryptage, un module cryptographique configuré pour encrypter un message à l'aide de la clé de cryptage obtenue afin d'obtenir un cryptogramme et un module de communication configuré pour envoyer le cryptogramme à un serveur distant de transaction. caractérisé en ce que ladite clé de cryptage a une durée de vie limitée ; et en ce que le module d'obtention de la clé de cryptage mobile est configuré pour, lorsqu'une précédente clé de cryptage obtenue par le dispositif mobile est périmée :
recevoir, d'un serveur distant sécurisé, une nouvelle clé de cryptage encryptée, obtenir une donnée personnelle saisie par un utilisateur sur une interface de saisie connectée au dispositif mobile,
décrypter la nouvelle clé de cryptage à l'aide de la donnée personnelle saisie, et supprimer la donnée personnelle du dispositif mobile avant d'utiliser ladite nouvelle clé de cryptage décryptée pour encrypter le message et obtenir le cryptogramme.
10. Produit programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 8 lorsque ledit programme est exécuté sur un ordinateur.
PCT/FR2015/052316 2014-09-02 2015-09-01 Sécurisation de clés de cryptage pour transaction sur un dispositif dépourvu de module sécurisé WO2016034812A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1458191 2014-09-02
FR1458191A FR3025341B1 (fr) 2014-09-02 2014-09-02 Securisation de cles de cryptage pour transaction sur un dispositif depourvu de module securise

Publications (1)

Publication Number Publication Date
WO2016034812A1 true WO2016034812A1 (fr) 2016-03-10

Family

ID=52007057

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2015/052316 WO2016034812A1 (fr) 2014-09-02 2015-09-01 Sécurisation de clés de cryptage pour transaction sur un dispositif dépourvu de module sécurisé

Country Status (2)

Country Link
FR (1) FR3025341B1 (fr)
WO (1) WO2016034812A1 (fr)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020133707A1 (en) * 2000-11-29 2002-09-19 Applied Microsystems Corporation Method and system for secure distribution of subscription-based game software
US20030054474A1 (en) 1998-06-22 2003-03-20 Genentech, Inc. Secreted and transmembrane polypeptides and nucleic acids encoding the same
WO2003098868A1 (fr) * 2002-05-17 2003-11-27 Nokia Corporation Procede et systeme utilises dans un reseau de communication de donnees sans fil numerique pour assurer un cryptage des donnees et serveur correspondant
WO2007138486A2 (fr) * 2006-01-31 2007-12-06 Cidway Technologies, Ltd. Système et procédé destinés à renforcer le degré de restriction lors d'accès à des applications logicielles
WO2012136986A1 (fr) * 2011-04-05 2012-10-11 Visa Europe Limited Système de paiement
US20130054474A1 (en) 2011-08-30 2013-02-28 C. Douglas Yeager Systems and methods for authorizing a transaction with an unexpected cryptogram

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030054474A1 (en) 1998-06-22 2003-03-20 Genentech, Inc. Secreted and transmembrane polypeptides and nucleic acids encoding the same
US20020133707A1 (en) * 2000-11-29 2002-09-19 Applied Microsystems Corporation Method and system for secure distribution of subscription-based game software
WO2003098868A1 (fr) * 2002-05-17 2003-11-27 Nokia Corporation Procede et systeme utilises dans un reseau de communication de donnees sans fil numerique pour assurer un cryptage des donnees et serveur correspondant
WO2007138486A2 (fr) * 2006-01-31 2007-12-06 Cidway Technologies, Ltd. Système et procédé destinés à renforcer le degré de restriction lors d'accès à des applications logicielles
WO2012136986A1 (fr) * 2011-04-05 2012-10-11 Visa Europe Limited Système de paiement
US20130054474A1 (en) 2011-08-30 2013-02-28 C. Douglas Yeager Systems and methods for authorizing a transaction with an unexpected cryptogram

Also Published As

Publication number Publication date
FR3025341B1 (fr) 2016-12-30
FR3025341A1 (fr) 2016-03-04

Similar Documents

Publication Publication Date Title
EP3221815B1 (fr) Procédé de sécurisation d'un jeton de paiement.
EP1549011A1 (fr) Procédé et système de communication entre un terminal et au moins un équipment communicant
EP3152860A1 (fr) Procédé d'authentification d'une première entité électronique par une seconde entité électronique et entité électronique mettant en oeuvre un tel procédé
EP3238474B1 (fr) Procédé de sécurisation de transactions sans contact
FR2822002A1 (fr) Authentification cryptographique par modules ephemeres
FR2919974A1 (fr) Systeme d'information et procede d'identification par un serveur d'application d'un utilisateur
EP2619941A1 (fr) Procede, serveur et systeme d'authentification d'une personne
FR3011653A1 (fr) Procedes et dispositifs de masquage et demasquage
EP3238200A1 (fr) Entité électronique sécurisée, appareil électronique et procédé de vérification de l'intégrité de données mémorisées dans une telle entité électronique sécurisée
EP0606792A1 (fr) Procédé d'authentification d'un ensemble informatique par un autre ensemble informatique
FR3002670A1 (fr) Procede et systeme de traitement cryptographique utilisant une donnee sensible
WO2016207715A1 (fr) Gestion securisee de jetons électroniques dans un telephone mobile.
WO2012031848A1 (fr) Procede simplifie de personnalisation de carte a puce et dispositif associe
WO2016034812A1 (fr) Sécurisation de clés de cryptage pour transaction sur un dispositif dépourvu de module sécurisé
WO2020064890A1 (fr) Procede de traitement d'une transaction, dispositif, systeme et programme correspondant
EP2285042A1 (fr) Module logiciel de sécurisation utilisant le chiffrement du haché d'un mot de passe concaténé avec une graine
FR2985148A1 (fr) Methode d'appairage d'equipements electroniques
EP1262860B1 (fr) Système et procédé d'authentification d'un utilisateur
EP2372945A1 (fr) Procédé de transmission sécurisée de données entre un terminal numérique et une plateforme de services interactifs
EP3758322A1 (fr) Procédé et système de génération de clés de chiffrement pour données de transaction ou de connexion
EP3340096B1 (fr) Procédé de configuration d'un programme cryptographique destiné à être exécuté par un terminal
FR2908194A1 (fr) Entite electronique portable et procede de blocage, a distance, d'une fonctionnalite d'une telle entite electronique portable
FR2903544A1 (fr) Procede de securisation d'une authentification par utilisation de plusieurs canaux
EP3029878B1 (fr) Procédé de transmission de secret à durée de vie limitée pour réaliser une transaction entre un terminal mobile et un équipement
WO2021099199A1 (fr) Procede et systeme pour le provisionnement ou remplacement securise d'un secret dans au moins un dispositif de communication portable.

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15767216

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15767216

Country of ref document: EP

Kind code of ref document: A1