FR2988250A1 - Procede de validation d'une transaction - Google Patents
Procede de validation d'une transaction Download PDFInfo
- Publication number
- FR2988250A1 FR2988250A1 FR1252413A FR1252413A FR2988250A1 FR 2988250 A1 FR2988250 A1 FR 2988250A1 FR 1252413 A FR1252413 A FR 1252413A FR 1252413 A FR1252413 A FR 1252413A FR 2988250 A1 FR2988250 A1 FR 2988250A1
- Authority
- FR
- France
- Prior art keywords
- information
- bits
- transaction
- code
- validating
- Prior art date
- Legal status (The legal status 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 status listed.)
- Withdrawn
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3215—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a plurality of channels
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
Abstract
L'invention a trait à un procédé de validation d'une transaction entre un premier dispositif (SRV) et un deuxième dispositif (PC) d'un utilisateur, l'utilisateur possédant en outre un dispositif (MOB), dit troisième dispositif, apte à communiquer avec le premier dispositif (SRV), caractérisé en ce qu'il comprend les étapes suivantes : - Une étape transmission d'une information (OTP) depuis le premier dispositif à destination à la fois du deuxième dispositif et du troisième dispositif, - Une étape de restitution de l'information sur les dispositifs, - Une étape de validation de la transaction s'il y a correspondance entre les informations restituées,
Description
Procédé de validation d'une transaction. Domaine technique L'invention se rapporte à un procédé de validation d'une transaction qui a pour objet par exemple la délivrance d'un service depuis un premier dispositif, dans lequel est hébergé un fournisseur de service, vers un deuxième dispositif, via un réseau de communication. Le procédé est apte à garantir que l'utilisateur du deuxième dispositif a qui sera délivré le service est bien l'utilisateur légitime. Le premier dispositif est typiquement un serveur apte à rendre un service logiciel et le deuxième dispositif un ordinateur. Les dispositifs impliqués dans l'invention sont d'une manière générale équipés de ressources physiques et logicielles incluant un processeur. Le réseau de communication en question est quelconque, par exemple le réseau Internet.
Etat de la technique De plus en plus de services sont maintenant accessibles via un ordinateur et Internet. Ces services nécessitent le plus souvent de connaître (et de vérifier) l'identité de l'utilisateur. Ainsi, il est possible de se connecter à sa banque via Internet, de faire des achats en ligne, de réserver des voyages ou encore de se connecter au réseau de son entreprise pour travailler à distance. L'authentification de l'utilisateur est donc primordiale. Dans beaucoup de cas, cette authentification se fait par un couple d'informations identifiant et mot de passe. Cependant, cette authentification simple a montré ses limites : - Mot de passe trivial choisi par les utilisateurs - Mot de passe recopié sur un papier à côté de l'ordinateur ; - Toujours le même mot de passe choisi pour tous les services ; - Dans certains cas, les mots de passe sont transmis en clair ; - Etc.
Un tiers peut donc espérer récupérer un mot de passe et l'utiliser à des fins malveillantes. Toutes ces limites rendent donc les moyens d'authentification actuels insuffisants. L'invention offre une solution ne présentant pas les inconvénients de l'état de la technique.
L'invention A cet effet, selon un aspect fonctionnel, l'invention a pour objet un procédé de validation d'une transaction entre un premier dispositif et un deuxième dispositif d'un utilisateur, l'utilisateur possédant en outre un dispositif, dit troisième dispositif, apte à communiquer avec le premier dispositif, caractérisé en ce qu'il comprend les étapes suivantes : - Une étape transmission d'une information depuis le premier dispositif à destination à la fois du deuxième dispositif et du troisième dispositif, - Une étape de restitution de l'information sur les dispositifs, - Une étape de validation de la transaction s'il y a correspondance entre les informations restituées. Une validation d'une transaction est donc précédée d'une validation de l'existence d'une correspondance entre deux informations restituées sur des dispositifs d'un même utilisateur ou groupe d'utilisateurs. L'existence d'une correspondance assure à l'utilisateur qu'il ne valide pas une action frauduleuse sur le deuxième dispositif. Le procédé de l'invention assure que l'utilisateur qui réalise une transaction au moyen du deuxième dispositif est un utilisateur légitime à savoir le porteur du troisième dispositif, de préférence préalablement authentifié. Selon un mode de mise en oeuvre particulier de l'invention, l'information est un code numérique et l'étape de transmission est précédée d'une étape de transformation du code en contenu multimédia. Ce mode facilite l'étape au cours de laquelle est vérifié si les deux codes restitués correspondent entre eux. En effet, si le code est un code binaire, la vérification consisterait à comparer chaque bit les uns après les autres.
Selon une première variante de ce mode, la transformation est basée sur un algorithme de chiffrement. Ainsi, si deux informations incluent des bits, et si les deux informations ne diffèrent que d'un nombre limité de bits, le code résultant du chiffrement fera apparaître une multitude de bits différents. La différence est donc plus visible.
Selon cette variante, si le code comprend une suite de bits, le résultat du chiffrement de ladite suite de bits comprend une série de bits chiffrée, et en ce que la transformation se base sur une partie de la série de bits chiffrée. Le nombre de bits utilisés étant réduit, on réduit d'autant la consommation de ressources dans le premier dispositif lors de la transformation.
Selon cette même variante, si l'algorithme de chiffrement de type CBC chiffre en série les bits par blocs, chaque chiffrement incluant le bloc courant à chiffrer et tout ou partie des blocs précédemment chiffrées, la partie de la série de bits chiffrés fait partie des derniers bits de ladite série de bits chiffrés. En effet, l'utilisation des derniers bits de la série résultant du chiffrement garantit une visibilité immédiate d'une éventuelle modification du code. Selon cette même variante, l'ordre des bits de la partie de bits chiffrés est inversé. Comme le mode utilisé est de type CBC, comme on l'a vu précédemment, si deux informations diffèrent, les derniers bits chiffrés ont plus de chance de faire apparaître la modification que les premiers, en conséquence une inversion de l'ordre des bits sélectionnés offre une garantie plus importante encore. Selon une deuxième variante, qui pourra être mis en oeuvre alternativement ou cumulativement avec la première variante, l'information incluant une série de bits, chiffrée ou non, la transformation inclut une étape d'exécution d'au moins un module ayant comme paramètre au moins un bit de la série, l'exécution d'un module entraînant la restitution d'un contenu multimédia. La restitution sur les écrans peut être réalisée de différentes manières dont les suivantes.
Selon une première manière, l'étape de validation de la transaction est précédée d'une étape de validation de la correspondance sur le troisième dispositif et d'une étape de transmission, depuis le troisième dispositif, de la validation au premier dispositif. Cette première manière garantit que l'utilisateur qui valide est bien l'utilisateur légitime.
Selon une deuxième manière qui pourra être mis en oeuvre alternativement ou cumulativement avec la première manière, l'information, dite première information, est restituée sur le deuxième dispositif, la restitution incluant en outre au moins une seconde information ; ensuite, l'étape de validation inclut en outre une étape de sélection de la première information sur le deuxième dispositif ; cette étape de validation est suivie d'une étape de transmission, depuis le deuxième dispositif, de la validation au premier dispositif. Cette deuxième manière garantit que l'utilisateur qui valide se situe bien à proximité du deuxième dispositif. Selon un aspect matériel, l'invention a trait à un système informatique comprenant un premier dispositif apte à communiquer via un réseau de communication avec au moins deux dispositifs, dit deuxième et troisième dispositif, le deuxième dispositif étant apte à réaliser une transaction avec le premier dispositif, caractérisé en ce que - le deuxième dispositif et le troisième comprennent des moyens de restitution respectifs aptes à restituer une information issue du premier dispositif, - et en ce que le troisième dispositif comprend des moyens de validation de la correspondance entre les informations restituées et des moyens de transmission aptes à transmettre la validation de la correspondance au premier dispositif. Dans ce système, conformément au procédé décrit ci-dessus, l'information restituée est un contenu multimédia.
L'invention a trait aussi à un dispositif, dit premier dispositif, comprenant des moyens de communication pour communiquer via un réseau de communication avec au moins deux dispositifs, dit deuxième et troisième dispositif, le deuxième dispositif étant apte à réaliser une transaction avec le premier dispositif, caractérisé en ce qu'il comprend les moyens suivants : - Des moyens de transmission d'une information à destination à la fois du deuxième dispositif et du troisième dispositif, - Des moyens de validation de la transaction s'il y a correspondance entre les informations restituées. Selon une variante, l'information est un code numérique ; Le premier dispositif comprend à cet effet des moyens de transformation du code en contenu multimédia. Enfin, l'invention a trait à un programme d'ordinateur apte à être mis en oeuvre sur le premier dispositif tel que défini ci-dessus, le programme comprenant des instructions de code qui, lorsqu'il est exécuté par un processeur réalise les étapes suivantes du procédé de l'invention défini ci-dessus - Une étape transmission d'une information depuis le premier dispositif à destination à la fois du deuxième dispositif et du troisième dispositif, - Une étape de validation de la transaction s'il y a correspondance entre les informations restituées, L'invention sera mieux comprise à la lecture de la description qui suit, donnée à titre d'exemple et faite en référence aux dessins annexés.
Les figures: La figure 1 représente un système informatique sur lequel est illustré un exemple de réalisation. Les figures 2 à 4 représentent les circuits des dispositifs impliqués dans le procédé de l'invention.
La figure 5 est un organigramme illustrant les différentes étapes de l'exemple de réalisation. La figure 6 est une vue d'écrans illustrant une variante de l'exemple de réalisation. Les figures 7a et 7b sont deux images respectives illustrant un résultat de l'étape de transformation décrite ci-dessus. Description détaillée d'un exemple de réalisation illustrant l'invention La figure 1 représente un système SYS comprenant un premier dispositif apte à communiquer avec un deuxième dispositif et un troisième dispositif. Ce premier dispositif est illustré au moyen d'un serveur SRV. Ce serveur héberge un service apte à être utilisé par le deuxième dispositif PC. Ce service est quelconque ; celui-ci peut être par exemple un service de fourniture d'un bulletin météo, ou d'informations. Le deuxième dispositif PC est illustré au moyen d'un ordinateur personnel apte à communiquer avec l'extérieur via un premier réseau de communication RES par exemple un réseau Internet.
Le système comprend aussi un troisième dispositif illustré au moyen d'un téléphone de radiocommunication MOB apte à communiquer via un deuxième réseau de communication par exemple un réseau dit de troisième génération 3G.
Dans notre exemple, les premier et deuxième dispositifs appartiennent à un même utilisateur UT, voire à un même groupe d'utilisateurs. L'ensemble des dispositifs décrits ci-dessus sont équipés de ressources physiques et logicielles. En l'espèce, en référence aux figures 2 à 4, le serveur comprend - un processeur CPU1, dit premier processeur, - des moyens de stockage MEM1, dit premiers moyens de stockage, - des moyens de communication COM1, dit premiers moyens de communication, pour communiquer avec l'extérieur via un réseau de communication L'ordinateur PC comprend - un processeur CPU2, dit deuxième processeur, - des moyens de stockage MEM2, dit deuxièmes moyens de stockage, - des moyens de restitution illustrés par un écran ECR2, dit deuxième écran, - des deuxièmes moyens de communication COM2 pour communiquer avec l'extérieur via le premier réseau de communication RES2 Le téléphone MOB comprend - un processeur CPU3, dit troisième processeur, - des moyens de stockage MEM3, dit troisièmes moyens de stockage, - des moyens de restitution illustrés par un écran ECR3, dit troisième écran, - des moyens de communication COM3, dits troisièmes moyens de communication, pour communiquer avec l'extérieur via un réseau de communication Dans chaque dispositif, les moyens sont reliés au processeur par l'intermédiaire d'un premier bus BUS1, d'un deuxième bus BUS2, et d'un troisième bus BUS3. Rappelons qu'un bus a pour fonction d'assurer le transfert de données numériques entre les différents circuits d'un terminal. Dans notre exemple, le bus en question inclut un bus de données et un bus de contrôle. A noter aussi que, dans notre exemple, les moyens de stockage décrits ci-dessus sont des mémoires permanentes, par exemple de type ROM (acronyme anglo-saxon de Read) et que les dispositifs incluent également une mémoire vive respective (non représentée) servant à stocker de manière non durable des données de calcul utilisées notamment lors de la mise en oeuvre du procédé. Un mode de réalisation est décrit en référence à la figure 5 sur laquelle est représentée un algorithme comprend les étapes d'un mode de réalisation du procédé de l'invention. On considère, dans notre exemple, qu'initialement l'utilisateur UT est déjà authentifié par exemple auprès d'un opérateur de télécommunication. On considère aussi que le fournisseur de services hébergé dans le serveur a connaissance de l'authentification réussie du deuxième terminal auprès de son opérateur, et qu'il entretien avec cet opérateur une relation de confiance Lors d'une première étape, l'utilisateur souhaite utiliser le service. Une requête (REQ->SRV) d'accès au service est transmise au serveur SRV.
Lors d'une deuxième étape, dans notre exemple, une authentification forte est réalisée. Lors de cette deuxième étape, l'utilisateur fourni des paramètres permettant de l'authentifier par exemple - un couple (ID/PW) comprenant un identifiant, un mot de passe ; - et un identifiant du téléphone par exemple le numéro de téléphone MSISDN. Une authentification forte n'est qu'un exemple de réalisation. Cette deuxième étape aurait pu consister simplement en la fourniture de l'identifiant du téléphone MSISDN uniquement.
Lors d'une troisième étape, une fois l'utilisateur authentifié, l'utilisateur accède au service par le biais de l'ordinateur PC, et réalise par exemple un achat (ACHT) d'un bien en ligne. Lors d'une quatrième étape, dans notre exemple, le serveur SRV génère un code numérique (OTP), de préférence à usage unique, et le transmet à la fois à l'ordinateur et au téléphone MOB déclaré lors de la deuxième étape. Rappelons que le terme anglo-saxon couramment utilisé par l'homme du mériter pour « code à usage unique » est «one time password ». Lors d'une cinquième étape, après réception, l'ordinateur et le téléphone restitue (RST-OTP->ECR1, RST-OTP->ECR2) sur l'écran les codes en 20 question. Lors d'une sixième étape, l'utilisateur compare les codes. S'ils sont identiques, l'utilisateur valide (VAL1) sur son téléphone le fait que les codes sont identiques, garantissant au fournisseur de service que l'utilisateur qui vient de valider est bien l'utilisateur légitime à savoir celui qui réalise la transaction par le 25 biais de l'ordinateur. A cet effet, en référence à la figure 4, le téléphone inclut des premiers moyens de validation MVAL1. Lors d'une septième étape, le serveur SRV reçoit la validation issue du téléphone et valide (SRV->VAL) l'achat du bien.
A noter que le code généré peut être un code numérique incluant tout caractère restituable, notamment sur un écran lorsque le code est un code visuel. A noter aussi que dans la présente description, il faut distinguer une validation de code faite au niveau du téléphone MOB, et éventuellement de l'ordinateur PC, d'une validation de transaction faite au niveau du serveur SRV. Le mode de réalisation décrit ci-dessus peut faire l'objet de variantes dont les suivantes. Le code numérique restitué peut être long ; l'étape de comparaison est donc difficile voir source d'erreur car nécessite de comparer chaque élément du code (bit par bit ou caractère par caractère). A cet effet, selon une variante du procédé, après la quatrième étape, après génération du code, ce dernier est transformé en image. De cette façon, lors de la cinquième étape, les images sont restituées en lieu et place du code. La sixième étape est donc simplifiée car elle se réduit à comparer deux images en lieu et place de codes incluant plusieurs bits ou caractères. La transformation décrite ci-dessus est avantageusement basée sur un algorithme de chiffrement connu de l'homme du métier. Dans notre exemple, l'algorithme de chiffrement est l'algorithme AES (sigle anglosaxon de « Advanced Encryption Standard ») de préférence avec un mode CBC (sigle anglosaxon de « Cipher Block Chaining ») connu de l'homme du métier. Selon le mode CBC, lors du chiffrement d'une information comportant plusieurs blocs de bits, un chiffrement d'un bloc se base sur le bloc courant à chiffrer et sur les blocs précédemment chiffrés. Ainsi, la moindre modification d'un bit d'un bloc a pour conséquence de faire apparaître cette modification à l'issu du chiffrement de ce bloc modifié, mais également des blocs suivants. Une image créée à la base du résultat du chiffrement de la façon décrite ci-après ferait donc apparaître clairement cette modification. Nous verrons dans la suite de la description comment les blocs de données issues du chiffrement sont transformés en image au moyen de modules logiciels MOD1-MODn (n est un nombre entier). L'algorithme AES-256 - chiffre des blocs de données multiples de 128 bits - avec une clé de 256 bits. En conséquence, si le code généré par le serveur n'est pas un multiple de 128 bits, des bits sont supprimés ou ajoutés au code généré afin de constituer un code multiple de 128 bits. Le plus souvent l'ajout est préféré dans les standards actuels.
Dans notre exemple, le code a un nombre de bits inférieurs. Le module de transformation ajoute donc un nombre de bits suffisant pour arriver à un multiple de 128 bits. Considérons que le code généré inclus K blocs de 128 bits. Le résultat du chiffrement au moyen de l'algorithme AES-256-CBC comporte également K blocs de 128 bits. Le procédé comprend une étape de création d'une image à partir des blocs résultants de l'étape de chiffrement. Le serveur SRV stocke en mémoire une pluralité de modules logiciels MOD 1-MODn qui transforme le code chiffré en figure géométrique à restituer sur les écrans. Le code chiffré est généralement très long. Si le nombre de bloc du code généré est K (K est un nombre entier), la longueur du code résultant du chiffrement est K*128bits. L'algorithme utilisé et le mode opératoire utilisé par le CBC sont tels que les derniers bits des derniers blocs suffisent pour être sûrs que le code généré initial a été modifié ou pas. Considérons que les derniers bits correspondant au résultat du chiffrement soit les suivants : B1024B1023....B4B3B2B1 = 00100101 Les derniers bits du code chiffré étant les plus probables d'apporter une indication sur une éventuelle modification faite par un tiers malveillant, une étape optionnelle consiste à inverser les derniers bits et obtenir l'ordre suivant : B1B2B3B4B5...B1024 = 10100100 Considérons les trois (n=3) modules logiciels ainsi que les paramètres respectifs suivants : - MOD1(B2, B3, B4), - MOD2(B6, B7), - MOD3(B9,B10) Afin de réduire le nombre d'exécution de module, un module s'exécute si le premier paramètre est précédé d'un bit égal à « 1 ». Ainsi, pour le premier module modulel, le premier bit B1 vaut 1 ; le modulel est donc exécuté. Les paramètres du modulel sont B2=0, B3=1, c=0.
A ce stade, il reste les bits suivants à traiter : 0100 Le chiffre suivant est un 0, donc le modulel ne sera pas exécuté. A ce stade, il reste les bits suivants à traiter : 100 Le chiffre suivant est un 1, le module3 est donc exécuté. Les paramètres du module3 sont B9=0 et B10=0.
Les modules peuvent être variés. La liste suivante donnée à titre d'exemple n'est pas exhaustive. Un module fournit par exemple : - un type de trait et épaisseur du cadre de l'image à restituer - une trame de fond de l'image à restituer et sa couleur - un type de trait et une épaisseur du trait d'une figure (rond, etc.) à restituer dans le cadre - une valeur, une couleur, une taille, un style et une position d'un caractère alpha numérique à restituer dans le cadre - une forme, une couleur, une amplitude et une fréquence d'une fonction mathématique à restituer dans le cadre. Les figures 7a et 7b illustrent deux images qui pourraient être créées grâce aux modules décrits ci-dessus. Selon une autre variante, le code généré est transformé en image sans 10 algorithme de chiffrement en utilisant uniquement les modules décrits précédemment. L'exemple de réalisation précédent est basé sur l'affichage de deux images, ci-après désignées par l'expression « premier code OTP1 » sur deux écrans, l'un sur le téléphone, l'autre sur l'ordinateur, et d'une validation effectuée 15 sur le téléphone. Selon une variante du mode de réalisation décrit ci-dessus, le serveur génère plusieurs codes OTP1 et OTP2, deux dans notre exemple. Dans cette configuration, les codes sont transmis à l'ordinateur à savoir sous la forme suivante 20 o un premier ensemble de codes, représenté par exemple sous forme de mosaïque ou de matrice, incluant le premier code OTP1 et d'autres codes illustrés par des lettres A à K sur la figure 7b et représenté dans notre exemple sous forme de matrice (ou mosaïque), et 25 o un deuxième code OTP2 Les codes sont également transmis vers le téléphone, à savoir : o le premier code OTP1, o le deuxième code OTP2. Dans cette configuration, en référence au mode de réalisation décrit ci-dessus, l'utilisateur valide le deuxième code OTP2 depuis son le téléphone si ce code est le même sur le téléphone et sur l'ordinateur ; De plus, l'utilisateur sélectionne sur l'écran de l'ordinateur le code OTP1 qu'il visualise sur son téléphone dans la matrice et valide sa sélection sur l'ordinateur grâce aux moyens de sélection MSEL3. L'ordinateur est équipé de deuxièmes moyens de validation MVAL2 pour valider la correspondance entre codes. La sélection s'effectue grâce à des moyens de sélection MSEL2 et MSEL3 présents sur le l'ordinateur PC et le téléphone, respectivement, par exemple une souris informatique dont le pointeur est représenté par une flèche sur la figure 6. Les moyens de sélection pourraient aussi être un écran tactile. A noter que l'ordre de validation par le biais des moyens de sélection est indifférent ; en effet, le deuxième code peut être validé avant le premier code ou inversement. Le serveur reçoit ainsi deux validations dont une émanant du téléphone et l'autre de l'ordinateur. Cette double action est une garantie supplémentaire prouvant que l'utilisateur est un utilisateur légitime et non un tiers malveillant.20
Claims (14)
- REVENDICATIONS1. Procédé de validation d'une transaction entre un premier dispositif (SRV) et un deuxième dispositif (PC) d'un utilisateur, l'utilisateur possédant en outre un dispositif (MOB), dit troisième dispositif, apte à communiquer avec le premier dispositif (SRV), caractérisé en ce qu'il comprend les étapes suivantes : - Une étape transmission d'une information (OTP1,OTP2) depuis le premier dispositif à destination à la fois du deuxième dispositif et du troisième dispositif, - Une étape de restitution de l'information sur les dispositifs, - Une étape de validation de la transaction s'il y a correspondance entre les informations restituées.
- 2. Procédé de communication selon la revendication 1, caractérisé en ce que l'information (OTP1,OTP2) est un code, et en ce que l'étape de transmission est précédée d'une étape de transformation du code en contenu multimédia.
- 3. Procédé selon la revendication 2, caractérisé en ce que la transformation est basée sur un algorithme de chiffrement.
- 4. Procédé selon la revendication 3, caractérisé en ce que le code comprend une suite de bits, en ce que le résultat du chiffrement de ladite suite de bits comprend une série de bits chiffrée, et en ce que la transformation se base sur une partie de la série de bits chiffrée.
- 5. Procédé selon les revendications 3 et 4, caractérisé en ce que l'algorithme de chiffrement (CBC) chiffre en série les bits par blocs, chaque chiffrement incluant le bloc courant à chiffrer et tout ou partie des blocs précédemment chiffrés, en ce que la partie de la série de bits chiffrés fait partie des derniers bits de ladite série de bits chiffrés.
- 6. Procédé selon la revendication 5, caractérisé en ce que l'ordre des bits de la partie de bits chiffrés est inversé.
- 7. Procédé selon la revendication 4, caractérisé en ce que l'information inclut une série de bits et en ce que la transformation inclut une étape d'exécution d'au moins un module ayant comme paramètre au moins un bit de ladite série, l'exécution d'un module entraînant la restitution d'un contenu multimédia.
- 8. Procédé selon la revendication 1, caractérisé en ce que l'information, dite première information, est restituée sur le deuxième dispositif (PC), la restitution incluant en outre au moins une seconde information (A-K), en ce que l'étape de validation inclut en outre une étape de sélection de la première information (OTP1) sur le deuxième dispositif (PC), et en ce qu'il comprend une étape de transmission, depuis le deuxième dispositif (PC), de la validation au premier dispositif.
- 9. Procédé selon la revendication 1 ou 8, caractérisé en ce que l'étape de validation de la transaction est précédée d'une étape de validation de la correspondance sur le troisième dispositif (MOB) et une étape de transmission, depuis le troisième dispositif (MOB), de la validation au premier dispositif.
- 10. Système informatique comprenant un premier dispositif (SRV) apte à communiquer via un réseau de communication (RES) avec au moins deux dispositifs (PC,MOB), dit deuxième et troisième dispositif, le deuxième dispositif étant apte à réaliser une transaction avec le premier dispositif, caractérisé en ce que - le deuxième dispositif (PC) et le troisième dispositif (MOB) comprennent des moyens de restitution (ECR2,ECR3) respectifs aptes à restituer une information (IMG1,IMG2) issues du premier dispositif, 2 9882 50 17 - et en ce que le troisième dispositif (MOB) comprend des moyens de validation (MVAL1) de la correspondance entre les informa tions restituées et des moyens de transmission aptes à transmettre la validation de la correspondance au premier dispositif (SRV). 5
- 11. Système selon la revendication 9, caractérisé en ce que l'information restituée est un contenu multimédia.
- 12. Dispositif (SRV), dit premier dispositif, comprenant des moyens de communication (COM1) pour communiquer via un réseau de communication avec au moins deux dispositifs, dit deuxième et troisième 10 dispositif, le deuxième dispositif étant apte à réaliser une transaction avec le premier dispositif, caractérisé en ce qu'il comprend les moyens suivants : - Des moyens de transmission d'une information (IMG1,IMG2) à destination à la fois du deuxième dispositif et du troisième dispositif, 15 - Des moyens de validation de la transaction s'il y a correspondance entre les informations restituées.
- 13. Dispositif selon la revendication 12, caractérisé en ce que l'information est un code numérique, et en ce qu'il comprend des moyens de transformation du code en contenu multimédia. 20
- 14. Programme d'ordinateur apte à être mis en oeuvre sur un dispositif tel que défini à la revendication 12, le programme comprenant des instructions de code qui, lorsqu'il est exécuté par un processeur réalise les étapes suivantes définies dans la revendication 1 : - Une étape transmission d'une information (OTP1,OTP2) depuis le 25 premier dispositif à destination à la fois du deuxième dispositif et du troisième dispositif, - Une étape de validation de la transaction s'il y a correspondance entre les informations restituées.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FR1252413A FR2988250A1 (fr) | 2012-03-16 | 2012-03-16 | Procede de validation d'une transaction |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FR1252413A FR2988250A1 (fr) | 2012-03-16 | 2012-03-16 | Procede de validation d'une transaction |
Publications (1)
Publication Number | Publication Date |
---|---|
FR2988250A1 true FR2988250A1 (fr) | 2013-09-20 |
Family
ID=46197479
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
FR1252413A Withdrawn FR2988250A1 (fr) | 2012-03-16 | 2012-03-16 | Procede de validation d'une transaction |
Country Status (1)
Country | Link |
---|---|
FR (1) | FR2988250A1 (fr) |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080086764A1 (en) * | 2006-10-06 | 2008-04-10 | Rajandra Luxman Kulkarni | Single-Party, Secured Multi-Channel Authentication |
WO2011075825A1 (fr) * | 2009-12-21 | 2011-06-30 | Kik Interactive, Inc. | Systèmes et procédés permettant d'avoir accès à des fichiers multimédias stockés à distance et de commander ces derniers |
-
2012
- 2012-03-16 FR FR1252413A patent/FR2988250A1/fr not_active Withdrawn
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080086764A1 (en) * | 2006-10-06 | 2008-04-10 | Rajandra Luxman Kulkarni | Single-Party, Secured Multi-Channel Authentication |
WO2011075825A1 (fr) * | 2009-12-21 | 2011-06-30 | Kik Interactive, Inc. | Systèmes et procédés permettant d'avoir accès à des fichiers multimédias stockés à distance et de commander ces derniers |
Non-Patent Citations (1)
Title |
---|
CYNTHIA KUO ET AL: "Low-cost Manufacturing, Usability, and Security: An Analysis of Bluetooth Simple Pairing and Wi-Fi Protected Setup", 1 January 2007 (2007-01-01), XP055025816, Retrieved from the Internet <URL:http://usablesecurity.org/papers/kuo.pdf> [retrieved on 20120426] * |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8225387B2 (en) | Method and system for access authentication | |
EP2619941B1 (fr) | Procede, serveur et systeme d'authentification d'une personne | |
EP0810506B1 (fr) | Procédé et dispositif d'identification sécurisée entre deux terminaux | |
WO2011138558A2 (fr) | Procede d'authentification d'un utilisateur requerant une transaction avec un fournisseur de service | |
WO2009019298A1 (fr) | Système d'information et procédé d'identification par un serveur d'application d'un utilisateur | |
WO2019233951A1 (fr) | Une application logicielle et un serveur informatique pour authentifier l'identité d'un créateur de contenu numérique et l'intégrité du contenu du créateur publié | |
CA3128869A1 (fr) | Methode cryptographique de verification des donnees | |
FR2964812A1 (fr) | Procede d'authentification pour l'acces a un site web | |
EP2568406B1 (fr) | Procédé de mise en oeuvre, a partir d'un terminal, de données cryptographiques d'un utilisateur stockées dans une base de données | |
WO2016207715A1 (fr) | Gestion securisee de jetons électroniques dans un telephone mobile. | |
FR2988250A1 (fr) | Procede de validation d'une transaction | |
EP2795947B1 (fr) | Méthode d'appairage d'équipements électroniques | |
WO2021116627A1 (fr) | Procede, serveur et systeme d'authentification de transaction utilisant deux canaux de communication | |
EP1406425B1 (fr) | Procédé de production, par un fournisseur d'accès, d'un identifiant isolant multimédia | |
EP2254275A1 (fr) | Procédé de chiffrement de parties particulières d'un document pour les utilisateurs privilèges | |
WO2023274979A1 (fr) | Procédé d'authentification de transaction utilisant deux canaux de communication | |
FR3141538A1 (fr) | Procede et dispositif de stockage en ligne reparti de fichiers dans un contexte zero confiance | |
FR3007929A1 (fr) | Procede d'authentification d'un utilisateur d'un terminal mobile | |
FR3017730A1 (fr) | Procede d'ouverture de session securise | |
CN113961909A (zh) | 一种客户端的免用户操作的登录方法及系统 | |
FR2888437A1 (fr) | Procede et systeme de controle d'acces a un service d'un fournisseur d'acces implemente sur un serveur multimedia, module, serveur, terminal et programmes pour ce systeme | |
EP3394780A1 (fr) | Procede et dispositif de connexion a un serveur distant | |
FR3026875A1 (fr) | Procedes de configuration d'un peripherique de type terminal connecte a un reseau afin de permettre une authentification forte d'un utilisateur | |
WO2013045793A1 (fr) | Procede de distribution de contenus, dispositif d'obtention et programme d'ordinateur correspondant |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
ST | Notification of lapse |
Effective date: 20131129 |