FR3090934A1 - Procédé et système de sécurisation d’opérations, et poste utilisateur associé - Google Patents

Abstract

Procédé et système de sécurisation d’opérations, et poste utilisateur associé Un procédé de sécurisation d’opérations comprend une étape (F30) de demande, par un utilisateur (U), de mise en œuvre d’une opération auprès d’un appareil (20) de prestataire de service, ce dernier émettant (F40) à un appareil (30) de certification une requête de validation de l'opération demandée tout en indiquant une clé (CL) associée à l’utilisateur (U). L’appareil (30) de certification identifie l’utilisateur associée à la clé (CL) et lui transmets (F60) une demande de code dynamique. Un dispositif (12) générateur de codes dynamiques affecté à l’utilisateur génère (F70) une première version (CC1) du code dynamique et le transmet (F80) à l’appareil (30) de certification qui le compare (F90) avec une seconde version (CC2) du code pour décider s’il convient ou non d’informer l’appareil prestataire de la validation de l’opération demandée. Figure pour l’abrégé : Fig. 2.

Description

Description

Titre de l'invention : Procédé et système de sécurisation d’opérations, et poste utilisateur associé

Domaine technique

[0001] L’invention se rapporte au domaine général de la sécurisation d’opérations (ex. une création de compte à un service quelconque ou un accès à ce compte ou de façon plus particulière un accès en ligne à un compte, un paiement en ligne, un paiement physique, et autres) par des moyens informatisés.

Technique antérieure

[0002] La sécurisation de ces opérations est un enjeu important aujourd’hui compte tenu de la prolifération de pirates qui cherchent à s’emparer des données d’identification et des données financières des utilisateurs. Plusieurs solutions ont été mises au point ces dernières années, en relation avec des opérations de types différents, mais ces solutions présentent toutefois un certain nombre de limites.

[0003] En ce qui concerne des transactions de paiement direct, c’est-à-dire des transactions non en ligne (chez des commerçants ou pour des retraits en espèce) : ces transactions se distinguent dans leurs versions de base par l’introduction d’une carte bancaire dans un terminal ou une borne de paiement lisant les données de ladite carte, la sécurisation de l’ensemble étant assurée par la saisie d’un code secret complémentaire connu de l’utilisateur seul. Le principal problème de sécurité à ce niveau est relatif au vol du code secret (par l’intermédiaire de bornes factices, par exemple).

[0004] Une approche intéressante et en croissance rapide est relatif aux paiements sans contacts de type NFC (pour « Near Field Communication »), pour lesquels il suffit d’approcher sa carte bancaire d’un terminal de paiement pour valider une transaction. L’intérêt est la simplicité pour l’utilisateur (un seul geste suffit), couplé avec un certain niveau de sécurité, puisque l’utilisateur ne saisit ni son numéro, ni son code secret, et donc ne les dévoile pas. A contrario, en cas de vol de la carte, le voleur n’a plus besoin de code secret. Pour limiter les effets de ces vols de carte le niveau maximum de prix par transaction et en cumulé par période est fixer à un seuil bas.

[0005] Les solutions de paiement sans contact par smartphone s’adressent au même usage avec une technologie proche associée à une sécurité, en général l’empreinte du doigt préalablement scannée du client ou celle de son visage ou iris. Ces dernières données peuvent cependant être piratées. L’usage est d’ailleurs ici de remplacer la carte bancaire par un smartphone pour la commodité de l’utilisateur plutôt que de sécuriser le processus.

[0006] En ce qui concerne des transactions en ligne liées aux cartes bancaires ces tran2 sactions se caractérisent dans leurs versions de base par la fourniture du numéro de carte, ce dernier étant sécurisé par la saisie d’un code complémentaire à 3 chiffres dit code CW (les appellations varient selon les banques). La sécurité reste faible, puisqu’il suffit aux pirates de récupérer le numéro et le code CW, ou encore de voler la carte.

[0007] Il existe des cartes à cryptogramme dynamique, telles celles incorporant la technologie de la société Idemia dont le code de confirmation à 3 chiffres, dit code CW, change régulièrement (toutes les heures par exemple). L’avantage est alors de réduire drastiquement l’intérêt d’un piratage en ligne, par exemple via un outil de keylogger, ou du fait d’un phishing à l’occasion d’une transaction sur un site marchand par exemple, du numéro de carte bancaire (lié au numéro de compte du client) et de ce code CW puisque les éventuels pirates ne pourront l’utiliser que sur un très bref laps de temps. Ce procédé est une réelle avancée côté transactions en ligne, même s’il ne couvre pas les cas de vol de la carte bancaire elle-même. Il est en outre inadapté aux problématiques de remboursement par le e-commerçant.

[0008] Le procédé dit codes secure des banques leur permet de demander une validation de transaction en ligne à leurs clients, après que ceux-ci aient saisi leurs données bancaires sur un site : à cet effet, elles leur envoient un code de validation sur leur mobile (lié au compte bancaire dans les bases de données internes des banques), charge au client de recopier ce code dans une interface dédiée s’affichant au niveau de l’interface de la transaction avant de retourner sur le site marchand.

[0009] Ce procédé est efficace mais plus onéreux que le précédent, et ne protège pas du cas de figure selon lequel le mobile et la carte bancaire sont volés, ces deux derniers étant souvent portés ensembles. Il n’empêche pas non plus le vol des données de la carte bancaire (numéro et code CW), et ce alors que la mise en œuvre du code sécure du fait de son coût n’est pas systématique. Enfin, des pirates aguerris arrivent à pirater le contenu du SMS reçu, quand le mobile est utilisé à la fois pour commander en ligne et recevoir le SMS avec le code sécure, usage qui tend à devenir majoritaire. La demande de brevet français publiée FR3044789 permet d’éviter cette dernière problématique, mais sa mise en œuvre est plus complexe et doit être réservée aux transactions de montant élevé ou aux process sécurisés.

[0010] Il y a aussi le cas des coordonnées bancaires stockées chez un commerçant en ligne. L'objectif est ici de simplifier l'expérience client lors d'une commande en ligne. Lors de la validation d'un panier, il suffit alors au client de sélectionner son moyen de paiement, et de confirmer la transaction par la saisie de son code CW. En termes de sécurité, il suffit donc au pirate de récupérer ce code CW, ou la carte bancaire / le mobile. Cette approche ouvre la porte aussi aux piratages des serveurs du ecommerçant, suivi de celui des codes CW des clients.

[0011] Dans tous les cas de figure précités, il reste donc des problématiques de sécurité.

[0012] Un autre maillon faible est en effet encore moins bien protégé et est relatif à la création par un utilisateur d'un compte sur un service quelconque (un service marchand par exemple, ou un service de petites annonces,...), et à la connexion de cet utilisateur à ce compte par simple identifiant et mot de passe, données pouvant être aisément hacquées par un pirate.

[0013] * Une approche un peu plus sécurisée consiste en la saisie de son code mot de passe à l'aide d'un tableau dynamique : affichage d'une image sur laquelle les chiffres ou lettres permis sont sur des cases, charge au client de cliquer sur les bonnes cases, le service récupérant la position des clics et en déduisant leur correspondance. Le piratage est un peu plus difficile, mais ne pose pas de problème à un expert du domaine.

[0014] * Une autre variante est la possibilité par l'offreur du service (ex. la banque) de communiquer un code de confirmation par un autre biais (ex. un autre email), ou en variante par une technologie proche du code secure (envoi d'un SMS de confirmation avec le code sur son mobile). Ce dernier cas de protection ne couvre pas les cas de vol du mobile (ou en variante le piratage du mail via l'identifiant et mot de passe pour accéder à son mail). En outre, selon ce cas de figure, on présume que le pirate dispose déjà de l'identifiant mot de passe du client, et une mauvaise réponse ne permettra que de bloquer le compte du client, ce qui générera d'autres problèmes.

[0015] Ces failles sont d'autant plus dommages que les vols de données d'identité sur les services en ligne sont en explosion.

Exposé de l’invention

[0016] L’invention pallie notamment les inconvénients précités en proposant un procédé de sécurisation d’opérations mis en œuvre au niveau d’un poste utilisateur, un procédé global de sécurisation d’opérations mis en œuvre au niveau d’un système comportant le poste utilisateur ainsi qu’un appareil de prestataire de service et un appareil de certification. On peut également appeler le procédé mis en œuvre au niveau du poste utilisateur « procédé de traitement d’une opération ».

[0017] L’invention prévoit, donc, un procédé de sécurisation d’opérations, comprenant : - une étape de formulation d’une demande, par un utilisateur (U) associé à une clé (CL) émise par un organisme de certification, de mise en œuvre d’une opération auprès d’un appareil de prestataire de service ;

- une étape de réception, par un poste utilisateur, d’une demande de code dynamique, destinée à l’utilisateur associé à la clé (CL), depuis un appareil de l’organisme de certification ;

- une étape de génération, par un dispositif générateur de codes dynamiques associé à la clé de l’utilisateur, d’une première version (CCI) du code dynamique ;

- une étape de transmission de la première version (CCI) du code dynamique à l’appareil de certification ; et

- une étape de réception, en provenance de l’appareil de prestataire de service, d’un message confirmant la réalisation de l’opération demandée, à condition que la première version du code dynamique corresponde à une deuxième version du code dynamique générée au niveau de l’organisme de certification.

[0018] Corrélativement, l’invention vise aussi un poste utilisateur comprenant :

[0019] une interface utilisateur configurée pour permettre à un utilisateur (U) associé à une clé (CL) émise par un organisme de certification de formuler une demande de mise en œuvre d’une opération auprès d’un appareil de prestataire de service ;

[0020] un premier module de réception destiné à recevoir une demande de code dynamique, destinée à l’utilisateur associé à la clé (CL), depuis un appareil de l’organisme de certification ;

[0021] un module de transmission à l’appareil de certification de codes produits par un dispositif générateur de codes dynamiques associé à la clé (CL) de l’utilisateur ; et [0022] un deuxième module de réception destiné à recevoir, depuis l’appareil de prestataire de service, un message confirmant la réalisation de l’opération demandée.

[0023] L’invention prévoit également un procédé global de sécurisation d’opérations, le procédé de sécurisation d’opérations comprenant :

- une étape de demande, par un utilisateur, de mise en œuvre d’une opération auprès d’un appareil de prestataire de service ;

- une étape d’émission par l’appareil de prestataire de service à un appareil de certification d’une requête de validation de l'opération demandée, ladite requête indiquant une clé (CL) associée à l’utilisateur ;

- une étape d’émission d’une demande de code dynamique, destinée à l’utilisateur associé à la clé (CL), depuis l’appareil de certification ;

- une étape de génération, par un dispositif générateur de codes dynamiques de l’utilisateur, d’une première version (CCI) du code dynamique ;

- une étape de transmission de la première version (CCI) du code dynamique à l’appareil de certification ;

- une étape d’acquisition d’une seconde version (CC2) du code dynamique et de comparaison des première et seconde versions du code dynamique par l’appareil de certification ; et

- à condition que les première et seconde versions (CC1,CC2) du code dynamique correspondent, une étape de transmission par l’appareil de certification à l’appareil de prestataire de service d’un signal indiquant la va lidation de l’opération demandée par l’utilisateur.

[0024] Corrélativement, l’invention vise aussi un système de sécurisation d’opérations, ce système de sécurisation d’opérations comprenant un appareil de prestataire de service et un appareil de certification, dans lequel :

[0025] l’appareil de prestataire de service comprend :

un module de réception d’une demande, par un utilisateur (U), de mise en œuvre d’une opération, un module d’émission vers l’appareil de certification d’une requête de validation de l'opération demandée, ladite requête indiquant une clé (CL) associée à l’utilisateur, et un module de mise en œuvre de l’opération demandée suite à la réception d’un signal de validation de la part de l’appareil de certification ; et

[0026] l’appareil de certification comprend :

un module d’émission d’une demande de code dynamique, destinée à un dispositif générateur de codes dynamiques affecté à l’utilisateur associé à ladite clé (CL), un module de réception d’une première version (CCI) du code dynamique générée par le dispositif générateur de codes dynamiques affecté à l’utilisateur associé à ladite clé (CL), un module d’acquisition d’une seconde version (CC2) du code dynamique, un module de comparaison des première et seconde versions (CC1,CC2) du code dynamique, et un module de transmission d’un signal de validation à l’appareil (20) de prestataire de service lorsque les première et seconde versions (CC1,CC2) du code dynamique correspondent.

[0027] Les procédés, le poste utilisateur et le système selon l'invention permettent d'éviter plusieurs inconvénients de l'état de l'art, en particulier ceux liés à la connexion d’un utilisateur à un compte en ligne. Par ailleurs, ces procédés, ce poste et ce système permettent de mettre en œuvre une double authentification pour les paiements en ligne assurant ainsi un niveau élevé de sécurité conforme à la directive européenne DSP2.

[0028] Dans certains modes de réalisation de l’invention, le poste utilisateur intègre son propre dispositif générateur de codes dynamiques. Toutefois d’autres solutions peuvent être employées, ex. l’emploi d’un dispositif générateur de codes dynamiques externe.

[0029] Dans certains modes de réalisation de l’invention, l’appareil de certification comporte son propre dispositif générateur de codes dynamiques configuré pour générer les mêmes codes que le dispositif affecté à l’utilisateur, aux mêmes moments.

Toutefois d’autres solutions peuvent être employées, ex. l’obtention de la seconde version du code depuis un dispositif externe.

[0030] Dans un mode particulier de réalisation, l’appareil de prestataire de service obtient un identifiant de la part de l’utilisateur et, à l’aide dudit identifiant, acquiert la clé (CL) associée à l’utilisateur, notamment depuis un de ses moyens de stockage ou depuis une source externe sure. La sécurisation de l’opération voulue par l’utilisateur devient d’autant moins onéreuse pour ce dernier, qui n’a plus besoin d’introduire un mot de passe associé à son identifiant. Par ailleurs, l’utilisateur peut se servir du même identifiant sur ses comptes auprès de plusieurs prestataires de service qui mettent en œuvre ce mode de réalisation, sans perte de sécurité, puisque c’est la clé CL associée à son compte, et non pas l’identifiant, qui sécurise la connexion.

[0031] Dans un autre mode de réalisation, l’étape d’émission de la requête de validation d'opération comprend l’émission d’une requête comportant des informations concernant l’opération demandée ; et le procédé comprend une étape de récupération de données de l’utilisateur associée à la clé (CL), cette dernière étape comprenant : • la récupération de données de contrôle indiquant au moins une restriction par rapport aux opérations permises, et • l’analyse des informations reçues concernant l’opération demandée pour déterminer si cette opération est ou non permise par rapport aux données de contrôle.

[0032] Cette étape de récupération de données de contrôle peut comprendre la récupération de données définissant au moins une restriction quant aux opérations permises en relation avec la clé CL. Ces données sont par exemple : une période temporelle pendant laquelle des opérations sont permises, une zone géographique où, ou à partir de laquelle, des opérations sont permises, un prestataire de service auprès duquel des opérations sont permises, et un prix associé à la réalisation de l’opération. Selon un mode particulier de réalisation, les restrictions définies par les données de contrôle peuvent être paramétrées par l’utilisateur, par exemple en fonction de l’usage qu’il compte faire de sa clé CL.

[0033] Les données de contrôle permettent de définir des bornes à l’usage de la clé affectée à l’utilisateur, ces bornes étant fixés par l’organisme de certification, par l’utilisateur ou par les deux. La sécurisation des opérations sera d’autant accrue que, entre autres, un pirate ne saura pas les restrictions qui s’appliquent à l’usage de la clé CL et ne saura pas adopter le comportement nécessaire pour satisfaire aux restrictions.

[0034] Par ailleurs, l’exploitation des données de contrôle offre des possibilités larges de paramétrisation du procédé / du système et permet de définir des applications spécifiques nouvelles sécurisées. Un grand avantage de ces paramètres tient à leurs combinaisons. Par exemple non exhaustif, outre leur intérêt pour la sécurisation des comptes, ces combinaisons permettent sans créer de nouveau compte et sans nécessiter une nouvelle carte de paiement, de transmettre une clé CL de paiement à un enfant en tant qu'argent de poche en le limitant à certains magasins, à une liste de sites marchand en ligne et/ou à un montant précis par mois. Ces combinaisons permettent également de donner une carte à clé CL avec un montant précis à son enfant qui va faire un stage à l'étranger, la clé étant valable dans ledit pays pour la période du stage.

[0035] L’exploitation des données de contrôle permet de réaliser un procédé anti-spam, le procédé global de sécurisation étant adapté comme suit :

[0036] la demande est formulée non pas par l’utilisateur mais par l’appareil de prestataire de service et comprend une demande de transmission d’un message à l’utilisateur associé à la clé (CL) ;

[0037] l’étape de récupération des données de l’utilisateur associée à la clé (CL), par l’appareil de certification, comprend la récupération de données de contrôle indiquant des paramètres anti-spam de l’utilisateur et la récupération des coordonnées de l’utilisateur ;

[0038] les étapes d’émission de demande de code dynamique, et de génération des première et seconde versions du code dynamique sont omises ; et

[0039] l’étape de transmission du signal de validation de l’opération demandée consiste en la transmission du message à l’utilisateur selon les coordonnées récupérées par l’appareil de certification lorsque l’appareil de certification constate que la transmission du message est compatible avec les paramètres anti-spam de l’utilisateur.

[0040] Selon ce procédé anti-spam, le prestataire de service SQ ne dispose pas des coordonnées de l’utilisateur, et l’appareil de certification permet la transmission à l’utilisateur du message du prestataire de service uniquement lorsque le message est conforme aux paramètres anti-spam définis en relation avec cet utilisateur. Ainsi, par exemple, l’utilisateur peut préciser le nombre de messages par tranche de temps qu’il accepte de recevoir de la part d’un prestataire de service spécifique et/ ou le moyen de communication (ex. SMS, courriel) par lequel il accepte de recevoir les messages.

[0041] Selon un mode de réalisation, le restrictions sont paramétrables par l’utilisateur. Par exemple, une interface utilisateur lui permet de modifier les paramètres associés à une clé CL donnée pendant une étape préalable du procédé ou à tout moment, par exemple en se connectant à son compte auprès de l'organisme de certification et en en sélectionnant la clé CL voulue.. L’utilisateur peut ainsi modifier une période de validité, des autorisations d’usage, des montants autorisés ... La modification n'aura aucun effet sur les utilisations historiques, mais sera applicable pour les utilisations futures de la clé CL. De cette manière, l’utilisateur obtient un niveau accru de contrôle sur les opérations sensibles qu’il réalise.

[0042] Dans un autre mode de réalisation, la génération de la première version du code dynamique par le dispositif générateur de codes dynamiques associé à la clé CL de l’utilisateur est déclenchée par une action de l’utilisateur. De cette manière, on réduit davantage la prédictibilité du code dynamique qui sera transmis à l’appareil de certification, réduisant encore la probabilité de piratage des données, puisqu’on dispose en plus de la variabilité associée à la génération dynamique des codes - d’une variabilité aléatoire à l’initiative de l’utilisateur.

[0043] Le déclenchement par une action de l’utilisateur, de la production d’un nouveau code par le dispositif générateur de codes dynamiques affecté à l’utilisateur implique un besoin de synchroniser le dispositif générateur de codes dynamiques côté appareil de certification avec le dispositif générateur de codes dynamiques côté utilisateur. Diverses approches conviennent pour réaliser cette synchronisation comme, par exemple, l’exploitation de séquences ordonnées de codes. Dans un mode particulier de réalisation, l’appareil de certification est configuré pour essayer de remédier à des écarts entre le positionnement dans la séquence de codes lorsqu’il constate que les première et seconde versions du code ne correspondent pas. A cette fin, l’appareil de certification peut mettre en œuvre un processus itératif qui consiste à acquérir une nouvelle version du code dynamique, à comparer la nouvelle version avec la première version (CCI) du code dynamique, et en cas de comparaison positive à constater la correspondance des codes mais en cas de comparaison négative à répéter les étapes du processus itératif jusqu’à ce qu’un nombre n de versions du code aient été acquises et comparées avec la première version du code. Ce processus peut être employé dans un mode de réalisation selon lequel le code dynamique comporte un sous-code (CCs) servant à ces fins de synchronisation et l’évolution du code dynamique comporte le changement progressif de chaque caractère du sous-code de synchronisation selon une règle respective. Par ailleurs, selon certains modes particuliers de réalisation, les caractères du sous-code de synchronisation sont distribués parmi les autres caractères du code dynamique.

[0044] Les mesures évoquées ci-dessus permettent d’assurer la bonne synchronisation entre les dispositifs générateur de codes dynamiques des deux côtés (utilisateur et organisme de certification) tout en obtenant un niveau de sécurité élevé.

[0045] Selon un mode particulier de réalisation, le poste utilisateur est pourvu d’un module d’actionnement, destiné à être actionné par l’utilisateur pour déclencher la génération d’un code par le dispositif générateur de codes dynamiques, et d’un capteur de données biométriques. Dans ce poste utilisateur, il est possible de le capteur de données biométriques obtienne des données biométriques de l’utilisateur lors de l’actionnement du module d’actionnement par l’utilisateur. Si le capteur de données biométriques ne valide pas les données biométriques détectées lors de ladite action de l’utilisateur, le module de transmission de codes ne transmet pas de code valable à l’appareil de certification (ex. aucun signal n’est transmis à l’appareil de certification ou un signal est transmis indiquant que des données biométriques erronées ont été détectées).

[0046] Selon un autre aspect, l’invention vise aussi un poste utilisateur comprenant un dispositif générateur de codes dynamiques, un module de transmission à un appareil de certification des codes produits par le dispositif générateur de codes dynamiques, et un capteur de données biométriques.

[0047] Le conditionnement de la transmission de la première version du code par la validité des données biométriques de l’utilisateur introduit dans le procédé un deuxième niveau d’authentification, permettant ainsi d’augmenter davantage la sécurité.

[0048] Dans un mode particulier de réalisation, l’étape d’émission de la demande de code dynamique par l’appareil de certification comprend la transmission à un poste de l’utilisateur d’informations concernant l’opération demandée. Ceci permet d’avertir l’utilisateur qu’un tiers cherche à réaliser une opération en se servant de la clé CL de l’utilisateur. L’utilisateur peut, donc, se servir de son poste pour transmettre à l’appareil de certification un signal de rejet de l’opération et l’appareil de certification n’émettra, donc, pas de signal de validation vers l’appareil de prestataire de service (par exemple un signal d’opération non validée sera transmis).

[0049] Dans un mode particulier de réalisation, l’étape d’émission de la demande de code dynamique par l’appareil de certification comprend la transmission à un poste de l’utilisateur d’une demande de renseignements complémentaires, et la validation de l’opération par l’appareil de certification est conditionnée par les renseignements complémentaires retournés par le poste utilisateur. En tant qu’exemple non limitatif, l’appareil de certification peut demander des données concernant la géolocalisation du poste utilisateur, et la validation de l’opération par l’appareil de certification est alors conditionnée par les renseignements de géolocalisation retournés par le poste utilisateur. Par exemple, l’appareil de certification vérifie si ces renseignements sont conformes aux données de contrôle associées à la clé CL de l’utilisateur. On peut ainsi ajouter une couche de sécurité au procédé / système de base.

[0050] Le procédé et le système de sécurisation d’opérations selon l’invention permettent la sécurisation de plusieurs types d’opérations sensibles différentes, par exemple : la création ou la connexion sécurisée à un compte, une transaction financière, une opération bancaire, un achat sur un site physique ou en ligne, un retrait d'espèces au niveau d’un automate, ou encore un service d'anti-spam innovant. Le grand intérêt du procédé et du système est la sécurisation accrue par rapport aux procédés de l’état de la technique, le tout avec une grande simplicité d'usage.

[0051] Le procédé permet une sécurisation forte lors de la création d'un compte, à la fois pour le prestataire de service et l'utilisateur, puisque la validation du compte est liée à un processus externe au service.

[0052] Le procédé permet selon un autre exemple une sécurisation forte lors de la connexion à un compte : le prestataire de service n'a en effet besoin que de l'identifiant de l'utilisateur (pas besoin de mot de passe, ni en variante d'autres informations personnelles) et de sa clé CL. Ces informations sont inexploitables pour un éventuel pirate sans la possession des différents dispositifs générateurs de codes dynamiques des clients concernés, en particulier si le prestataire de service ne stocke pas les données personnelles qui peuvent lui être retournées en fin de procédé.

[0053] Côté expérience utilisateur, selon divers modes de réalisation de 1‘invention celui-ci se contente de saisir son identifiant, puis de recopier ensuite son code CC.

[0054] Il en va de même pour les transactions financières en ligne. Le e-commerçant ne craint plus le risque de piratage, puisqu'il stocke en regard du client une clé CL sans rapport avec un numéro de carte bancaire (et éventuellement valable que pour cet ecommerçant pour des montants prédéfinis par période). L'utilisateur en lieu et place de la saisie d'un numéro de carte bancaire, puis des dates de fin de validité et du code CW, ne saisit que le code CC généré par son dispositif générateur de codes dynamiques. De plus, ce dispositif est compatible avec des procédés de l'état de la technique.

[0055] Dans un mode particulier de réalisation, les différentes étapes du procédé de sécurisation sont déterminées par des instructions de programmes d’ordinateurs. En conséquence, l’invention vise aussi des programmes d’ordinateur sur des support d’informations respectifs, ces programmes étant susceptibles d’être mis en œuvre dans l’appareil de prestataire de service, dans l’appareil de certification et dans un poste utilisateur, ou plus généralement dans un ordinateur, ces programmes comportant des instructions adaptées à la mise en œuvre des étapes d’un procédé informatisé de sécurisation d’opérations tel que décrit ci-dessus.

[0056] Ces programmes peuvent 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.

[0057] L’invention vise aussi des supports d'informations lisibles par un ordinateur, et comportant des instructions des programmes d'ordinateur tels que mentionnés cidessus.

[0058] 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.

[0059] 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 par11 ticulier téléchargé sur un réseau de type Internet.

[0060] 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.

[0061] On peut en outre également envisager, dans d'autres modes de réalisation, que le procédé de sécurisation, le système de sécurisation, et le poste utilisateur selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées. Brève description des dessins

[0062] [fig.l]

La figure 1 représente, de façon schématique, un système de sécurisation conforme à l’invention dans un mode particulier de réalisation ;

[0063] [fig.2]

La figure 2 représente, sous forme d’ordinogramme, les principales étapes d’un procédé global de sécurisation d’opérations selon l’invention ;

[0064] [fig.3]

La figure 3 représente, de manière schématique, les principales interactions entre les éléments du système lors du déroulement du procédé de la figure 2 ;

[0065] [fig.4]

La figure 4 représente, sous forme d’ordinogramme, les principales étapes d’un procédé de sécurisation d’opérations selon un mode de réalisation de l’invention au niveau d’un poste utilisateur ;

[0066] [fig.5]

La figure 5 représente l’architecture d’un poste utilisateur conforme à l’invention dans un mode particulier de réalisation ;

[0067] [fig.6]

La figure 6 représente l’architecture d’un appareil de prestataire de service conforme à l’invention dans un mode particulier de réalisation ;

[0068] [fig.7]

La figure 7 représente l’architecture d’un appareil de certification conforme à l’invention dans un mode particulier de réalisation ;

[0069] [fig. 8]

La figure 8 représente l’architecture matérielle d’un poste utilisateur conforme à l’invention dans un mode particulier de réalisation ; et

[0070] [fig.9]

La figure 9 représente, sous forme d’ordinogramme, les principales étapes d’un procédé anti-spam selon un mode de réalisation de l’invention.

Description des modes de réalisation

[0071] La figure 1 représente, de façon schématique, un système de sécurisation conforme à l’invention dans un mode particulier de réalisation. Il convient de noter que l’exemple représenté sur la figure 1 se rapporte à un système comprenant un poste utilisateur ainsi qu’un appareil de prestataire de service et un appareil de certification. A titre d’alternative, le système ne comporte pas de poste utilisateur et l’utilisateur U introduit les données nécessaires (ex. un identifiant, la première version du code généré de manière dynamique et, éventuellement, la clé CL) en se servant de moyens fournis, par exemple, par le prestataire de service.

[0072] Dans l’exemple envisagé à la figure 1, le système 1 de sécurisation d’opérations comprend un poste utilisateur 10, un appareil 20 de prestataire de service et un appareil 30 de certification qui communiquent entre eux via un réseau 40 (ex. Internet, réseau téléphonique, WAN, LAN, réseau filaire ou sans fils, etc..).

[0073] Le poste utilisateur 10 peut être un téléphone mobile, une tablette, un PC, ou tout autre dispositif d’un utilisateur U. Typiquement, l’appareil 20 de prestataire de service consiste en un serveur ou un groupe de serveurs opérés par un prestataire de service SQ, éventuellement associé à d’autres équipements. Le prestataire de service SQ peut être un marchand, une banque etc... Typiquement, l’appareil 30 de certification consiste en un serveur ou un groupe de serveurs opérés par un organisme de certification CERT, éventuellement associé à d’autres équipements. L'organisme de certification CERT peut être une banque, un opérateur mobile ou tout autre type d'organisme susceptible d'émettre une clé CL et de proposer aux prestataires de services SQ un moyen standardisé conforme à celui décrit ci-dessous.

[0074] Nous allons maintenant décrire, en référence aux figures 2 et 3, les principales étapes mises en œuvre lors du procédé de sécurisation d’opérations selon l’invention dans un mode particulier de réalisation. Ce procédé peut être mis en œuvre par le système représenté à la figure 1. La figure 2 représente, sous forme d’ordinogramme, les principales étapes du procédé et la figure 3 représente, de manière schématique, les principales interactions entre les éléments du système lors du déroulement du procédé.

[0075] Selon certains modes particuliers de réalisation, le procédé représenté sur la figure 2 peut comporter une phase ou étape préalable (EP) au cours de laquelle une clé CL est affectée à l’utilisateur U. Cette étape préalable EP peut, notamment, comprendre une première sous-étape L10 selon laquelle l’utilisateur formule auprès de l’organisme de certification une requête tendant à produire (générer) une clé CL et l’affectation à l’utilisateur de cette clé CL. L’organisme de certification CERT transmet la clé CL à l’utilisateur dans une sous-étape E20 et typiquement transmet aussi à ce dernier un dispositif DC générateur de codes dynamiques. A titre alternative, l’utilisateur possède déjà un dispositif générateur de codes dynamiques et à ce stade n’obtient de l’organisme de certification CERT que la clé CL générée.

[0076] Lorsque l’utilisateur U souhaite entreprendre une transaction ou autre opération, notamment une opération sensible, en employant sa clé CL, l’utilisateur formule une demande DEM_OP auprès du prestataire de services SQ (L30) lors d’une première étape El du procédé.

[0077] Ensuite, lors d’une deuxième étape E2 du procédé, l’appareil 20 de prestataire de service transmet à l’appareil 30 de certification une requête REQ_VAL(CL) de validation de l'opération demandée, ladite requête indiquant la clé CL associée à l’utilisateur U (E40).

[0078] Lors de la troisième étape E3 du procédé, l’appareil 30 de certification identifie l’utilisateur associée à la clé CL, par exemple en réalisant une recherche dans une base de données au moyen de la clé CL. Selon certains modes de réalisation de l’invention l’appareil 30 de certification récupère (E50) des données de contrôle, enregistrées lors de la phase préalable EP, associées à l’usage de la clé CL et effectue certains contrôles, par exemple par rapport à des informations concernant l’opération demandée par l’utilisateur U, ces informations ayant été transmises à l’appareil 30 de certification par l’appareil 20 de prestataire de service (ex. dans un message qui comporte la clé CL). Eventuellement, l’appareil 30 de certification peut d’ores et déjà transmettre à l’appareil de prestataire de service un message indiquant que l’opération demandée est en-dehors des usages permis pour la clé CL (E55). Ensuite, l’appareil 30 de certification émet une demande REQ_CC de code dynamique, destinée à l’utilisateur associé à la clé (CL) (E60). Bien entendu, si l’appareil de certification a déjà indiqué au prestataire de services SQ que l’opération demandée n’est pas valable le procédé peut s’arrêter à l’étape E55. Dans un système selon l’exemple représenté sur la figure 1, l’appareil 30 de certification peut transmettre la demande REQ_CC au poste utilisateur 10, sous la forme d’un formulaire qui sera affiché à l’écran.

[0079] Suite à réception de la demande REQ_CC transmise par l’appareil 30 de certification, et lors de la quatrième étape E4 du procédé, le dispositif DC générateur de codes dynamiques associé à la clé CL de l’utilisateur produit une première version CCI du code dynamique (E70). Selon certains modes de réalisation de l’invention, le dispositif DC générateur de codes dynamiques est doté d’un moyen d’impulsion (ou autre moyen actionnable par l’utilisateur) et le code dynamique est généré suite à l’actionnement de ce moyen d’impulsion par l’utilisateur. S’ensuit une étape (E80) de transmission d’un message TX_CC1 comprenant la première version CCI du code dynamique à l’appareil 30 de certification.

[0080] Le procédé se termine avec une cinquième étape E5 au cours de laquelle l’appareil (30) de certification acquiert une seconde version (CC2) du code dynamique et compare celui-ci avec la première version du code et, à condition que les première et seconde versions (CC1,CC2) du code dynamique correspondent, transmet à l’appareil de prestataire de service un signal TX_RES indiquant la validation de l’opération demandée par l’utilisateur U (F100). Bien entendu, en cas de résultat négatif de la comparaison, l’appareil 30 de certification peut transmettre au prestataire de services SQ un message indiquant que l’opération demandée n’a pas été validée. Eventuellement d’autres renseignements peuvent être transmis à l’appareil de prestataire de service à la fin de l’étape E5. Par ailleurs, le résultat de la comparaison (F90) peut procurer la réalisation d’autres opérations par l’appareil 30 de certification (ex. la mise à jour du montant d’un crédit associé au code CL).

[0081] Nous allons maintenant exposer plus en détails différentes manières de réaliser les étapes EP et El à E5 représentés sur les figures 2 et 3.

L’Etape Préalable (EP)

[0082] Lors de l'étape préalable EP du procédé, l'organisme chargé de certifier les opérations (ex. les transactions ou les connexions) fournit à futilisateur une clé CL associée à un dispositif DC de codes à cryptogramme dynamique CC (ce dispositif DC étant soit déjà détenu par l’utilisateur soit fourni à l'utilisateur par l’organisme de certification lors de l’étape EP).

[0083] Moyens d’obtention de la clé CL associé à l’utilisateur

[0084] A cet effet, selon un mode de réalisation préféré, ledit utilisateur doit en premier lieu s'inscrire auprès dudit organisme de certification CERT et lui fournir différents éléments : son nom, son prénom, le ou les moyens de le contacter (tel, mail), etc.

[0085] L'inscription peut se faire en ligne (éventuellement à l'aide d'un procédé tel que celui de l’invention) ou en physique, comme pour une agence bancaire traditionnelle. Elle peut également être mixte : par exemple une l^ère phase d'inscription en ligne et une seconde phase après livraison d’un dispositif DC physique à son adresse pré-indiquée (par exemple son adresse postale, dans un lieu convenu tel qu'un relais,...).

[0086] Les données (utilisateur) associées à la clé CL

[0087] Selon un mode de réalisation, futilisateur demande une clé CL à son organisme de certification et précise différents paramètres, correspondant à différents types d'informations que l'organisme de certification liera à ladite clé CL d'une façon ou d'une autre, par exemple grâce à une base de données, ou tout autre moyen de gestion de la persistance de ces données, dédié dudit organisme de certification. La liste des types d'informations peut être très variable, et nous n'en citons ici qu'un sous ensemble non exhaustif. Certaines des informations serviront de données de contrôle mais d’autres correspondent à des métadonnées associées à l’utilisateur (bien entendu certaines informations peuvent remplir les deux rôles).

[0088] Par exemple, les types d'informations peuvent être relatifs :

• Aux utilisateurs de la clé CL :

[0089] * Si aucun nom n'est précisé, le lien peut être fait avec le nom de futilisateur U-Init tel qu'indiqué lors de son inscription (tel qu'indiqué lors de la description du début de l'étape préalable).

[0090] * L'utilisateur peut préciser un autre nom tiers, ou un alias (nom qu'il souhaite lier à cette clé CL).

[0091] * L'utilisateur peut éventuellement préciser plusieurs noms, si la clé a vocation à être partagée (un peu à l'image d'un compte joint).

[0092] Pour ces différents cas, en reprenant l'exemple du lien à l'aide d'une base de données, l'organisme de certification gérera l'association de la clé CL avec son propriétaire UInit et la ou les différentes identités complémentaires U-Comp ci-dessus.

[0093] Il est possible d’ajouter des données complémentaires à chaque identité U-comp (facultatif), selon, par exemple la ou les législations en vigueur dans le pays concerné :

[0094] * L'âge de U-Comp (si la clé est par exemple attribuée à un enfant mineur de U-Init) ou en variante le statut correspondant (mineur ou majeur,...). Par défaut ce paramètre est initialisé par celui de U-Init.

[0095] * S'il s'agit d'une personne morale ou physique (plus les précisions éventuelles :

raison sociale ...).

[0096] * Le ou les identités de communication associées, éventuellement distinctes de celles de U-Init (par exemple numéro de tél, identifiant de messagerie, email,...), et en variante le moyen associé (envoi par SMS par exemple).

• Aux autorisations de divulgation à SQ des informations liées à la clé CL : [0097] En tant qu’exemples non exhaustifs, on peut citer l’autorisation ou non de divulgation du nom, prénom, âge, adresse, un moyen de communication,.....Une auto- risation par défaut peut être fournie sur tout ou partie de ces données en l'absence de précision. Ladite diffusion des données dont l'utilisateur accepte la divulgation peut par exemple non exhaustif être effective à l’étape E5 du procédé et dispositif.

• Aux autorisations d'usage (par SQ) liées à la clé CL

[0098] Autorisations données toujours à SQ. Par exemple non exhaustif, ces autorisations d'usage sont utilisées dans les cas d'usage d'antispam, décrits en fin du présent document.

• Aux opérations sécurisées / usages de la clé CL

[0099] De façon facultative, au moins un usage spécifique donné de la clé CL peut être précisé. Les exemples d'usages sont nombreux.

[0100] A titre d’exemple non exhaustifs, les usages sont :

[0101] * une inscription et/ou une connexion à un site Internet ou une application,

[0102] * un abonnement à un service quelconque (journaux ou magazine papier,...),

[0103] * un paiement générique physique ou en ligne,

[0104] * un paiement dans au moins un magasin spécifique (tel magasin de telle chaîne de supermarchés par exemple).

[0105] * un paiement en ligne sur au moins un site marchand.

[0106] Selon les demandes de l'utilisateur, une clé CL peut ainsi voir son usage restreint à des formalités d'inscription et de connexion ou de paiement en ligne, ou les 2, éventuellement sur un site précis ...

[0107] Une clé peut donc avoir plusieurs usages (à ne pas confondre avec les autorisations d'usage) : par exemple inscription, connexion à un site et paiement en ligne sur ledit site.

[0108] En l'absence de restriction d'usage, la clé CL peut servir à tous les usages possibles pour l'utilisateur concerné. Ces restrictions d'usage sont en effet facultatives. L'utilisateur peut n'utiliser qu'une seule clé pour se connecter / s’inscrire sur différents sites ou services sans préciser lesquels, voir payer sur lesdits sites s'il s'agit de sites marchands. Mais il ne pourra pas alors bénéficier des intérêts cités ci-dessus et ni ceux qui seront précisés par la suite.

• Aux autres restrictions lors de l’usage de la clé CL

[0109] De façon facultative, au moins une restriction peut être définie en relation avec un usage de la clé CL. Les exemples de restrictions sont nombreux, et seulement quelques-uns sont cités ci-après :

[0110] * restrictions en termes de durée, ou de période de validité de la clé CL.

[0111] Eventuellement, il peut y avoir plusieurs périodes de validité associées à ladite clé.

[0112] * restrictions en termes de zone de géolocalisation

[0113] Ces restrictions peuvent être apportées, par exemple pour limiter les utilisations d'une clé CL à une zone géographique donnée, par exemples non exhaustifs au niveau d'un pays ou au niveau de la localisation géographique d'un magasin précis.

[0114] * restrictions en termes de montant (en relation avec des usages de type paiement)

[0115] Par exemple, un montant maximum, et éventuellement un montant par période (avec éventuellement de montants distincts selon les périodes) peuvent être précisés.

[0116] A ce niveau également, il est possible de préciser si les paiements se font uniquement à l'acte ou si des abonnements sont acceptés (les restrictions en termes de durée et périodes décrites ci-avant permettent d'en limiter la portée).

[0117] Moyens pour réaliser le paramétrage des informations de contrôle associées à la clé CL

[0118] Des moyens classiques peuvent être employés pour permettre à l’utilisateur de préciser ses souhaits lors du paramétrage des informations de contrôle. Il n'entre pas dans le cadre de cette demande de brevet de préciser tous les moyens connus mais, par exemple non exhaustif, lors d'une demande de clé CL, et ce quel que soient les moyens mis en œuvre pour ladite demande (physique dans une agence, par téléphone, en ligne via des formulaires de l'organisme de certification), l'utilisateur peut préciser les données relatives à ladite cible, éventuellement à l'aide de listes de références dis17 ponibles au niveau de l'organisme de certification.

[0119] En tant que d’autres exemples non exhaustifs :

[0120] * Dans le cas d'une clé destinée à un paiement en ligne, l'utilisateur peut préciser l'option paiement en ligne.

[0121] * Dans le cas d'une clé destinée à un paiement pour une personne, l'utilisateur peut préciser l'option paiement générique.

[0122] Selon un autre exemple, lors d'une demande en ligne, l'utilisateur peut préciser inscription à un service, puis sélectionner dans une liste de services connus, voire rajouter manuellement le nom (et éventuellement l'url correspondant au nom de domaine dans le cas d'un site Internet) dudit service ou site si celui-ci n'est pas dans la liste des sites connus.

[0123] En variante, ledit service correspondant à SQ fourni lui-même, préalablement à l'étape préalable, le nom ou code nom sur lequel il est référencé chez les organismes de certifications, dans le cas où une liste de référence de ces services existe.

[0124] Les paramètres peuvent aussi être présentés en dépendance les uns des autres.

[0125] Ainsi, sans restriction préalable, l'utilisateur peut formuler une demande de restriction en termes de montant de paiement pour pouvoir préciser lesdits montants et modalités associées. Cette option n’est automatiquement proposée au client que si pour sa clé CL un usage de paiement a été indiqué.

[0126] La combinaison de ces différents types de données de paramétrage liés à la clé CL peut nécessiter des contrôles aux étapes ultérieures: par exemple une clé CL permettant le paiement physique uniquement dans tel magasin peut nécessiter tout ou partie des contrôles suivants lors des étapes ultérieures: process de paiement non en ligne, transmission de données du vendeur pour vérifier leur concordance avec celles en regard de la clé, géolocalisation éventuelle du vendeur à contrôler par rapport à celle en regard de la clé,.... Un avantage du procédé et système selon ce mode de réalisation de l’invention, en dehors de son extrême paramétrabilité, est qu’à aucun moment le vendeur, ou le pirate ne connaît les données de contrôle associées à ladite clé.

[0127] Par ailleurs, comme nous l’avons évoqué ci-dessus, un avantage important de ces paramètres découle des combinaisons que l’on peut en faire.

[0128] Le moment du paramétrage des informations utilisateur associées à CL

[0129] A noter que, selon certains modes de réalisation de l’invention, l'utilisateur peut non seulement modifier les paramètres associés à une clé CL donnée au cours de l’étape préalable EP mais aussi à tout moment. L’utilisateur peut réaliser la modification voulue en se connectant à son compte auprès de l'organisme de certification, puis en sélectionnant la clé CL voulue, puis en modifiant lesdits paramètres.

[0130] La clé CL

[0131] Selon un mode particulier de réalisation de l’invention la clé CL est le numéro d’une carte bancaire, éventuellement couplé à une date de fin de validité, et le code CC est ledit code à cryptogramme dynamique. L'entité tenant le rôle d'organisme de certification est alors un organisme bancaire.

[0132] Pourtant, malgré tous ses intérêts (technologie mature, acteurs en place, identification automatique de l'organisme de certification (ici la banque) via le numéro de carte,...), cette implémentation présente quelques inconvénients: les API (d’après l’anglais « application programming interface », ou interface de programmation applicative) entre les sites marchands et leur banque sont déjà en place et sont distinctes selon les organismes bancaires (qui s'échangent ensuite les données de transaction de façon normalisée), pas d'adaptation pour la validation de données tierces aux données marchandes, retour d'informations différentes de celles envisagées par le procédé et dispositif décrits ici....

[0133] Selon un mode de réalisation, la clé CL fournie par l'organisme de certification ne correspond pas forcément au numéro d'une carte bancaire, mais est une clé unique destinée audit utilisateur. Cette clé est composée d'un nombre prédéfini de caractères successifs (ex. chiffres et/ou lettres). En variante, cette succession de symboles peut incorporer également des caractères spéciaux.

[0134] Cette clé unique peut être fournie électroniquement à l'utilisateur, ou sous toute autre forme. Elle peut ainsi éventuellement être matérialisée sur une carte plastique à l'image des cartes bancaires.

[0135] Selon un mode de réalisation particulièrement, à l'image des cartes bancaires, la clé CL incorpore dans le code de cette clé un moyen permettant d'identifier l'organisme de certification, ce qui permet de normaliser cette succession de caractères, et permet des APIs standardisées indépendantes des organismes de certifications. Un autre avantage de cette variante est bien entendu que lesdites clés CL sont globalement uniques : pas de doublon possible sur le marché.

[0136] Par exemple, si ladite clé était composée de 16 caractères, les 12 premiers peuvent être dédiés à la clé spécifique de rutilisateur et les 4 derniers à l'identification de l'organisme émetteur. Auquel cas, ladite liste des organismes de certifications et leur code est unique quel que soit la clé CL.

[0137] Le cas des organismes bancaires proposant des clés CL visualisables sur une carte bancaire et incorporant éventuellement un dispositif de cryptogrammes dynamiques étant connu, les explications suivantes sont positionnées par rapport à ces cas pour mieux expliquer les intérêts de la solution.

[0138] Selon une l^ère variante, la clé CL correspond à un numéro de carte bancaire, éventuellement combiné à une date de fin de validité, et le dispositif DC de codes à cryptogramme dynamique CC correspond à celui disponibles sur les cartes à cryptogramme dynamique, avec le code à 3 chiffres (dit code CW) changeant périodiquement, selon une méthode et avec des moyens déjà expliqués ci-avant. Nous avons toutefois déjà évoqué les inconvénients de cette l^ère variante, relativement en particulier à la rigidité des procédures déjà en place et à leur faible évolutivité.

[0139] Selon une autre variante, la clé CL n’est pas un numéro de carte et peut comporter une succession de lettres et ou de chiffres, avec certaines séquences et positions normalisées afin en particulier de reconnaître l'organisme de certification comme déjà indiqué. La clé est par exemple communiquée à l’utilisateur, électroniquement ou par tout autre voie par l'organisme de certification. En variante, elle est apposée et visible sur un support quelconque, tel qu'une carte plastifiée par exemple.

[0140] Comme exposé par la suite, selon un mode de réalisation, des éléments de codage de la clé CL peuvent permettre de retrouver de façon certaine l'organisme de certification émetteur de ladite clé CL.

[0141] Selon un des modes de réalisation, des éléments de codage de la clé CL (par exemple non exhaustif le 1 l^ème et ou le 12ème caractère de la clé) permettent de préciser des restrictions d'usage particulières de ladite clé quand il y en a : par exemple non exhaustif, une clé n'ayant pas de restriction aurait A en 1 l^ème caractère tandis qu'une clé ne pouvant être utilisée que pour une demande d'inscription aurait I en 1 l^ème caractère.

[0142] Un dispositif DC peut être associé à plusieurs clés CL

[0143] L'utilisateur peut indiquer des données valables pour un usage par défaut, puis demander la création, par l’organisme de certification, de différentes clés avec des données distinctes (en particulier s'il destine une desdites clés à un tiers, tel qu'un enfant par exemple) ou partiellement distinctes.

[0144] Disposer pour toutes ses clés, ou pour une partie d'entre elles, d'un seul dispositif DC simplifie grandement la tâche de l’utilisateur (pas besoin d'avoir 5 cartes (ou bagues, montres,...) avec chacune un de ces dispositifs DC). En variante, il peut disposer d'un nombre limité de dispositifs DC : par exemple, un premier destiné à ses comptes auprès de différents services et un autre destiné à ses moyens de paiement.

[0145] Selon un autre mode de réalisation, plusieurs dispositifs DC de l'utilisateur sont combinés sur un même support. Par exemple non exhaustif, un support tel qu'une bague à écran dispose de 2 dispositifs DC et d’écran d'affichage respectif, un 1^er écran destiné à l'affichage des clé CC du 1^er dispositif correspondant par exemple à des clés d'accès à des services variés, un second écran destiné à l'affichage des clé CC du 2ème dispositif correspondant par exemple à des clés d'accès à des paiement en ligne.

[0146] Selon une autre implémentation possible, ledit support ne dispose que d'un seul écran d’affichage et un moyen tel que par exemple non exhaustif un bouton poussoir permet de passer d'un type d'affichage à l'autre, ce moyen étant distinct d’un moyen d'impulsion éventuellement présent dont se sert l’utilisateur pour générer la prochaine valeur du code dynamique. Auquel cas, un indice visuel, ex. un symbole ou une couleur, au niveau de l'affichage permet de distinguer chacun des 2 dispositifs DC.

[0147] Selon une l^ère variante, ledit dispositif commun DC dispose d'un moyen pour afficher les différentes clés qu'il supporte, afin que l'utilisateur sélectionne la clé voulue pour obtenir le code CC en cours (ou impulsé) correspondant. Cette variante complexifie toutefois le dispositif DC et en rend en outre l'usage complexe : Si par exemple une clé CL comprend une série de 16 chiffres et ou lettres, il faut que l'utilisateur se remémore à quel usage correspond chacune de ces suites un peu rébarbatives.

[0148] Dans un mode de réalisation préféré, le dispositif DC génère un code CC selon une des implémentations détaillées ci avant, indépendamment du choix d’une clé. Le lien entre ce dispositif DC et une ou plusieurs clés CL de l'utilisateur est alors conservé uniquement au niveau des bases de données de l'organisme de certification. Cette dernière variante, outre la suppression des inconvénients cités ci-avant, présente comme autre intérêt pour l'utilisateur de pouvoir à tout moment rajouter ou supprimer de nouvelles clés CL liées à ce dispositif DC, ceci sans avoir à modifier ledit dispositif (il suffit d'effectuer l'ajout ou la suppression dudit lien entre CL et DC dans les bases de l'organisme de certification).

[0149] Par exemple, par ce biais, un utilisateur peut disposer d'une bague dotée d'un tel dispositif DC à impulsion, générant à la demande un code cryptogrammique CC, et utiliser ledit code dans les étapes suivantes du procédé et dispositif pour

[0150] a) Sécuriser une inscription ou une connexion sur un site A auquel correspond une 1 ^ère clé CL

[0151] b) Sécuriser une inscription ou une connexion sur un site A ou B auquel correspond une 2^ème clé CL pour laquelle il diffuse d'autres données d'identité (un alias par exemple)

[0152] c) Un paiement en ligne en indiquant une 3^ème clé CL (et en permettant au site considéré de la conserver pour les échanges suivants),

[0153] d) Un paiement en ligne avec le numéro de sa carte bancaire qui tient alors lieu de 4 ^ème clé CL, le code CW n'ayant même plus besoin d'être inscrit au verso de ladite carte (puisqu'il est déporté dans notre exemple sur la bague de l’utilisateur (selon un autre exemple d'implémentation, le dispositif DC est incorporé dans la carte bancaire et est utilisé pour tous les exemples d’usages).

[0154] e) Sécuriser sa connexion au site de la banque ayant émis ladite carte, ce qui correspond à une 5^ème clé CL La Première Etape : El

[0155] Au cours de la première étape, El, l'utilisateur demande la réalisation d’une opération auprès d’un appareil d’un service quelconque SQ. Les opérations visées sont très variées. En voici certains exemples données à titre non limitatif : une demande de création de compte, une demande d’initiation de transaction, une demande d’accès à un local ou à une ressource physique ou numérique (ex. demande d’ouverture ou de démarrage d’une voiture, demande d’entrée de maison particulière ou d’entreprise), etc.. A cette occasion il indique ou associe sa clé CL et l'organisme de certification. Selon la variante selon laquelle la clé CL inclut le code de l'organisme de certification, l’utilisateur n’a pas besoin de fournir cette information à l'occasion de cette étape El.

[0156] Le type d'opération (création de compte, connexion à un compte, début d'une transaction de paiement,...) peut être déterminé implicitement lors de cette étape El.

[0157] Si par exemple l'utilisateur clique ou appuie sur un bouton de type Créez votre compte, l’appareil du service SQ déterminera qu'il s'agit d'une création de compte, et cette information sera utilisée dans la suite du procédé.

[0158] Selon un mode de réalisation, une API normalisée est mise à disposition de l’appareil du service SQ par l'organisme de certification et permet à celui-ci de sélectionner un type d'opération, puis de fournir les informations complémentaires requises en fonction de ce type d'opération. Selon cette variante, cette même API servira pour les différents échanges de données entre l’appareil de SQ et l'organisme de certification lors des étapes ultérieures du procédé.

[0159] 1^er exemple : l'utilisateur sélectionne une opération de type Création de compte auprès de l’appareil du service SQ.

[0160] La seule information utile à fournir par l'utilisateur est la clé CL. En fonction de la configuration effectuée à l'étape préalable, la clé CL est soit destinée uniquement à des usages au niveau du service SQ, soit à des usages plus généraux dont le service SQ.

[0161] Mais comme on le verra plus loin à l'occasion de la description d'autres types d'opérations, se limiter à cette seule information peut être problématique pour l'utilisateur étant donné que cela lui impose de retenir la composition de ladite clé associée à son usage sur le service SQ.

[0162] De ce fait, en plus de la clé CL, l’appareil du service SQ peut proposer à l'utilisateur de remplir un formulaire comportant des informations complémentaires, telles qu'un identifiant de connexion par exemple. Par exemple non exhaustif, ledit identifiant est un numéro de téléphone personnel ou un email personnel. Selon une autre variante, le formulaire d'inscription inclut d'autres informations telles que par exemple non exhaustif le nom, prénom et par exemple adresse voire une autre donnée de contact dudit utilisateur.

[0163] Toutefois, selon un mode de réalisation, ces informations complémentaires sont fournies lors des étapes ultérieures par l'organisme de certification, si l'utilisateur l'a autorisé, et non par l’utilisateur.

[0164] 2^ème exemple : l'utilisateur sélectionne une opération de type Connexion à un compte auprès du service SQ.

[0165] A noter que la mise en œuvre de ce 2^ème exemple implique qu'auparavant l'utilisateur ait sélectionné une opération de type « Création de compte » auprès du service SQ, puis enchaîné de façon positive l'ensemble des étapes du procédé selon un mode de réalisation de l’invention relativement à cette création de compte auprès du service SQ à l'aide d'une clé CL appropriée. En clair, il dispose déjà d'un compte auprès de SQ, compte qui a été créé à l'aide du procédé et dispositif décrits.

[0166] En variante, si l'utilisateur s'est inscrit audit service SQ via un processus d'inscription classique, pour pouvoir par la suite se connecter à ce même service au moyen du procédé et dispositif décrits, il devra avoir préalablement complété son profil auprès dudit service SQ en rajoutant sa clé CL. Suite à cette mise à jour, l'utilisateur pourra par la suite se connecter à l'aide d’un procédé et système mettant en œuvre l’invention. Auquel(s) cas, pour se connecter audit compte auprès de SQ, l'utilisateur doit indiquer la clé CL liée à ce compte.

[0167] Comme nous l'avons vu ci-avant, une telle mise en œuvre nécessite que l'utilisateur se remémore la composition de la clé CL, ce qui si celle-ci se compose de par exemple non exhaustif 16 lettres ou chiffres, n'a rien d'évident. Selon un mode de réalisation, l'utilisateur saisit l'identifiant de connexion personnel qu'il a indiqué à l'occasion de la création de son compte lors d'une opération précédente. Grâce à la mise en œuvre du procédé et dispositif, il n'a pas à saisir de mot de passe à cette étape. L’appareil du service SQ récupère alors la clé CL associée au compte de l'utilisateur dans un de ses moyens de stockage tel qu'une base de données au niveau dudit service SQ, clé CL que ledit utilisateur a indiquée en regard de cet identifiant de connexion à l'occasion de la création de son compte ou lors d'une opération de mise à jour ultérieure de son compte sur ledit service. Les moyens de stockage peuvent être internes ou externes à l’appareil 20 du service SQ.

[0168] 3^ème exemple, l'utilisateur sélectionne une opération de type « Paiement en ligne » après avoir sélectionné un article ou constitué un panier auprès du service SQ.

[0169] Deux cas de figure sont à distinguer :

[0170] a) La clé CL que l'utilisateur a indiqué pour ledit service SQ sert à la fois pour s'inscrire, et ou se connecter et également au paiement en ligne. Auquel cas, une fois connecté à l’appareil du service SQ comme décrit ci-avant, l’utilisateur n'a rien à indiquer. Il lui suffit à cette étape de valider le montant de son panier ou le montant de la transaction, et d'attendre les interactions issues des étapes ultérieures du procédé.

[0171] b) L'utilisateur utilise une autre clé CL en guise de moyen de paiement, que cette clé CL soit générique pour tous ses paiements ou ait été à l'étape initiale limitée aux usages sur le service SQ.

[0172] Dans le 1^er cas, il peut s'agir par exemple non exhaustif du numéro indiqué au verso d'une carte bancaire compatible avec notre procédé et dispositif. Dans les autres cas distincts des cartes bancaires, il peut s’agir d'une clé CL quelconque. Auquel cas, il suffit à l'utilisateur d'indiquer le numéro ou ladite suite de sa clé CL de paiement, et d'attendre les interactions issues des étapes ultérieures.

[0173] Contrairement aux procédés et dispositifs de l'état de l'art, l'utilisateur peut sans aucune crainte, en particulier dans les cas distincts des numéros de carte bancaire, faire conserver sa clé de paiement au niveau dudit service SQ, puisque comme nous le verrons par la suite ladite clé sera inutilisable par d'éventuels pirates sans disposer du dispositif DC associé.

[0174] Sans compter la sécurisation renforcée de façon drastique, il en résulte aussi une expérience client sans équivalent côté paiement : en lieu et place de la validation d'un montant suivi de la saisie de ses coordonnées bancaires, l'utilisateur n'a à cette étape plus qu'à valider son montant de paiement.

[0175] Bien entendu, si le site marchand est limité aux APIs de paiement classique, la solution prévue ici est compatible puisque le même numéro de carte peut servir selon les voies de l'état de l'art antérieur pour accéder à des services marchands non affiliés à notre procédé (il suffira à l'utilisateur de saisir ses coordonnées bancaires de façon classique directement à cette étape: numéro de carte bancaire, date de fin de validité et code CW généré par le dispositif DC), et pour accéder à des services SQ affiliés à notre procédé.

La Deuxième Etape : E2

[0176] Au cours de Γ étape, E2 du procédé, l’appareil 20 du prestataire de service SQ demande à l'organisme de certification la validation de l'opération effectuée à l’étape El. Cette étape consiste ici à communiquer audit organisme de certification, la clé CL sélectionnée par l'utilisateur à l’étape El, et de façon concomitante les données contextuelles correspondant à ladite opération.

[0177] Selon un mode de réalisation, ladite transmission des informations est normalisée et s'effectue au travers d'une interface (API) fournie par un organisme tiers OT auquel s'est affilié ledit service SQ pour cette API (cet organisme tiers peut aussi être un organisme de certification, mais la clé CL n'est pas forcément gérée par ce dernier, mais par un organisme de certification quelconque du marché), interface détaillant les procédures d'interactions avec les différents services de certification du marché ainsi que la typologie des données échangées.

[0178] Selon cette variante, outre la clé CL associée à l'utilisateur, l’appareil du service SQ fournit de façon normalisée différentes informations en relation avec le type d'opération demandé par l'utilisateur à l’étape El.

[0179] Par exemple, l’appareil du service SQ fournit à l’organisme de certification, la clé CL de l’utilisateur et une codification correspondant à l'opération réalisée. Il peut également fournir une clé KSQ, propre à l’appareil du service SQ.

[0180] La codification est par exemple une suite des 3 lettres.

[0181] Cette codification est par exemple CRE pour une création de compte, CNX pour une connexion à un compte, PAY pour un paiement en une fois (dit paiement one shot), PAYn pour un paiement en plusieurs fois (avec en données associées le nombre de fois,...), PAYAb pour un paiement par abonnement avec en données associées la durée de l'abonnement, le montant périodique ...,

[0182] De multiples autres usages sont possibles (par exemple un virement sur un compte tiers ou vers une autre clé). Chaque usage est associé à un code spécifique et à une ou plusieurs informations complémentaires liées au type d'opération (par exemple pour un virement, outre le mot clé de type VIR, un montant, un compte ou une clé tierce et une indication ‘échéance).

[0183] A noter que les traitements du programme d'API implémentés au niveau de l’appareil du service SQ permettent également de faire au niveau du service SQ une l^ère série de contrôles, tels que par exemple vérifier la conformité de la clé CL (nombre de caractères, détermination de l'organisme de certification (en fonction du code correspondant inclus dans la clé,...) et selon la variante détaillée en fin d'étape préalable vérifier si ladite clé est autorisée pour ce type d'opération (également en fonction du code correspondant inclus dans la clé à la position prédéfinie pour ces contrôles ...).

[0184] Selon une autre mode de réalisation, la clé CL fournie par l’appareil du service SQ permet au niveau de l'organisme de certification, ou au niveau d’un organisme tiers OT auquel s'est affilié ledit service SQ pour cette API, qui transmettra ensuite les informations recueillies à l'organisme de certification, de récupérer les informations nécessaires au procédé selon l’invention et concernant le service SQ, telles que par exemple le nom du service SQ, l'URL du nom de domaine concerné (ou un identifiant d'application sur un store quelconque, de type Apple Store ou Play store par exemple non exhaustif). D'autres informations par exemple relatives aux coordonnées géographiques dudit service SQ s'il s'agit d'un magasin physique par exemple (informations fournies lors de l'inscription de SQ au service fournisseur de sa clé API) peuvent être fournies à cette occasion.

[0185] La personne du métier comprendra que d'autres variantes d'implémentation sont possibles à ce niveau mais non détaillées ici par souci de concision. Par exemple, seule la clé est fournie, et l'organisme de certification demande à l’appareil du service SQ des informations complémentaires.

[0186] Selon une l^ère variante d'implémentation, une table de correspondance incluse au niveau des traitements du programme d'API implémentés au niveau de l’appareil du service SQ permet à partir de la détermination de l'organisme de certification correspondant à la clé CL (via la série de codes dédiés au sein de la clé CL) de trouver l'adresse (par exemple non exhaustif de type URL) de l'organisme de certification à interroger. Auquel cas, l’appareil du service SQ interroge directement, de préférence au travers d'un lien sécurisé (par exemple de type https) ledit organisme de certification à l'adresse convenue selon cette table de correspondance en lui transmettant de façon normalisée les informations décrites ci-dessus. Cette l^ère variante est plus rapide, mais nécessite une mise à jour fréquente, de la table de correspondance utilisée par les multiples services SQ.

[0187] Selon une autre variante d'implémentation, la demande du service SQ est transmise à l'organisme tiers OT, qui après avoir éventuellement récupéré les informations associées à la clé KSQ API de SQ dans les moyens de stockage dudit service tiers OT, reroute la demande du service SQ, ainsi que l'ensemble des données associées récupérées depuis la demande initiale ou déterminées via l'exploitation des données de la clé API, vers les services de l'organisme de certification correspondant.

La Troisième Etape : E3

[0188] Au cours de T étape, E3, du procédé, l’appareil 30 de l'organisme de certification CERT reçoit la clé CL et, éventuellement, les informations associées issues des étapes El ou E2, identifie l'utilisateur correspondant à cette clé dans ses bases de données, et transmet à cet utilisateur une demande de fourniture de code dynamique (par exemple en lui transmettant un formulaire de validation).

[0189] Cette étape E3 débute par la réception par un moyen de réception conçu à cet effet au niveau de l'organisme de certification, de la demande émanant du service SQ, par l'intermédiaire éventuel du service tiers OT.

[0190] Ledit moyen de réception récupère et classe alors les différentes informations contenues dans la requête :

[0191] a) Il détermine les données relatives à l'identification du service SQ, données fournies soit lors de l'inscription dudit service SQ au niveau du service OT, soit directement au niveau de l'organisme de certification.

[0192] b) Il détermine le type d'opération demandée par analyse du code correspondant (par exemple CRE pour création de compte).

[0193] c) En fonction du type d'opération demandée, il récupère également les données complémentaires nécessaires (par exemple non exhaustif, pour une demande de paiement, le montant de la demande) et les informations éventuellement associées (par exemple s'il s'agit d'un paiement en plusieurs fois, du nombre de fois et du montant à chaque échéance,...).

[0194] d) il récupère également la clé CL.

[0195] La transmission de ces informations à l'organisme de certification peut se faire en exploitant diverses solutions connues qui ne sont pas toutes détaillées ici. Par exemple non exhaustif, ces informations sont transmises via un formulaire XML ou un fichier json, ou encore en mode Post depuis l'organisme tiers OT vers l'organisme de certification. De multiples autres méthodes plus ou moins sécurisées sont possibles.

[0196] Un moyen d’interrogation de l’appareil 30 de l'organisme de certification est alors mis en œuvre pour déterminer par interrogation de ses moyens de stockage (des bases de données par exemple) à quel utilisateur (ou alias) appartient la clé CL fournie. Les différentes informations associées décrites plus haut, sont récupérées par ce moyen d’interrogation.

[0197] Sont en particulier récupérées à ce niveau l'ensemble des données particulières associées à l'utilisateur de la clé CL (le nom ou alias, le ou les moyens de communication associées,...) indiquées pour cette clé CL à l'occasion de l'étape préalable. Sont également récupérées les informations relatives aux autorisations de divulgation ainsi que les restrictions diverses en termes d'usage en particulier.

[0198] Un moyen de contrôle est alors mis en œuvre pour contrôler les données transmises à l'occasion des étapes El et E2 par rapport aux données relatives en particulier aux usages et restrictions d'usages acceptées pour ladite clé CL. Les analyses et comparaisons possibles sont connues et ne sont pas toutes détaillées ici.

[0199] * Par exemple non exhaustif, ce moyen de contrôle permet de vérifier qu’une codification de transaction associée à la clé CL est conforme à ou aux transactions autorisées pour cette clé CL dans les moyens de stockage de l'organisme de certification.

[0200] * Selon un autre exemple, si la clé CL au niveau des moyens de stockage de l'organisme de certification est associée à un site ou à une application précise SA, ce moyen de contrôle vérifie que les données complémentaires associées à la clé CL et relatives au service SQ correspondent bien audit site ou application SA.

[0201] * Selon un autre exemple encore, le moyen de contrôle vérifie que le plafond de paiement de futilisateur associé à ladite clé CL, éventuellement sur une période donnée, n'est pas dépassé.

[0202] La personne du métier saura comment se servir de moyens connus pour implémenter les mesures indiquées ci-dessus et ils ne seront, donc, pas détaillés ici, y compris : la comparaison des libellés et / ou de montants, la référence des 2 côtés (du côté de ΓΑΡΙ et du côté de l'organisme de certification) à une base de données centrale des services SQ possibles, etc....

[0203] Si les résultats des analyses et comparaisons effectuées par ce moyen de contrôle ne sont pas conformes à celles attendues, le procédé est stoppé et le service SQ est informé de l'échec de la transaction.

[0204] Dans le cas inverse, le procédé se poursuit et un moyen de sélection permet de sélectionner des coordonnées de communication associée à la clé CL de futilisateur, et éventuellement un moyen de communication associé, et génère l'envoi vers l'utilisateur d'un formulaire de validation.

[0205] Selon une autre variante possible mais moins sécuritaire, le moyen de communication vers l'utilisateur se fait via des coordonnées de communication (email, numéro de mobile de l'utilisateur,...) indiquées par l'utilisateur au niveau du service SQ et transmis par ce dernier à l'occasion de la étape E2 .

[0206] Selon un mode de réalisation, des données complémentaires et relatives à la demande transmise par le service SQ sont associées audit envoi. Il peut par exemple s'agir d'une série d'informations qui permettent lors de l’étape E4 d'indiquer à l'utilisateur que le formulaire de validation est lié à une demande de création de compte de tel service, ou de connexion à tel service, ou encore de paiement de tel montant pour tel service, pour reprendre les 3 exemples déjà évoqués ci-avant.

[0207] Selon un autre mode de réalisation, des données complémentaires et relatives à des restrictions d'usage liées dans les bases de stockage de l'organisme de certification à la clé CL, sont associées audit envoi. Il peut par exemple non exhaustif s'agir, si la clé CL est liée à une restriction d'usage sur une zone géographique précise (par exemple lié à un magasin physique), d'une requête de contrôle de la géolocalisation de l'utilisateur. La Quatrième Etape : E4

[0208] Lors de l’étape, E4, le poste 10 de l’utilisateur réceptionne la demande de fourniture du code généré de manière dynamique. Par exemple, au niveau de son poste (téléphone portable, tablette, etc.) l’utilisateur reçoit et puis complète un formulaire avec un code cryptogrammique généré par son dispositif DC associé à sa clé CL.

[0209] Comment l’utilisateur reçoit la demande de CC

[0210] Il y a plusieurs manières pour l’appareil de certification de formuler sa demande de code dynamique et pour présenter cette demande au niveau de l’utilisateur notamment sur un poste de l’utilisateur (ex. téléphone portable, PC, tablette). Dans l’exemple décrit ci-dessous, l’appareil de certification transmet au poste utilisateur un formulaire de validation. Il convient de noter que l’invention n’est pas être limitée par rapport à cette manière de présenter la demande de code dynamique.

[0211] Un moyen de réception permet de réceptionner le formulaire de validation et les données complémentaires éventuelles associées, puis de présenter à l’utilisateur ledit formulaire de validation. De nombreux procédés connus permettent ce type de réception et affichage.

[0212] Selon un 1^er exemple, l'utilisateur reçoit un email en provenance de l'appareil de certification, email incluant un lien relatif au formulaire. Le mail peut contenir lui-même les informations complémentaires relatives à la transaction.

[0213] Selon un 2^ème exemple, l'utilisateur reçoit un SMS en provenance de l'appareil de certification, email incluant un lien relatif au formulaire. Le SMS peut contenir lui-même les informations complémentaires relatives à l’opération.

[0214] Selon un 3^ème exemple, l'utilisateur reçoit sur sa messagerie instantanée un message incorporant le formulaire, et éventuellement les détails liés à la transaction.

[0215] Selon un 4^ème exemple, à l'instar des formulaires de validation lors de certaines tran sacrions financières, ΓΑΡΙ entre le service SQ et l'appareil de certification, par l'intermédiaire éventuel du service OT déjà cité, coopère afin que le formulaire de validation soit transmis à l’appareil du service SQ et affiché à la suite (quelques secondes au maximum) de la demande de l'utilisateur au niveau du dispositif via lequel l’utilisateur a formulé sa demande, sans que celui-ci ait à ouvrir une autre application.

[0216] Selon un 5^ème exemple un formulaire intégré à un robot (« bot » en anglais) de service marchand est transmis à rutilisateur. Le formulaire peut ne comporter qu’une zone de saisie et un bouton de validation. En variante, il peut comporter une zone textuelle rappelant le contexte de la demande (par exemple, demande de création de compte sur tel service, ou demande de paiement en 3 fois de tel montant sur tel service, ...).

[0217] A noter que dans le cadre des paiements en ligne, un des avantages d’un procédé selon l’invention, au moins du point de vue de l'utilisateur, est la suppression du temps minimal de réponse des procédés connus (durée de validité associée à un code ...). Une implémentation similaire à celle des 4^ème et 5^ème exemples est particulièrement adaptée, pour des demandes nécessitant une réponse rapide. Par contre, si l’opération demandée accepte un délai conséquent, une implémentation similaire à celle des exemples 1 à 3 indiqués ci-dessus sont possibles (envoi par mail,...).

[0218] Demande de CC accompagnée d’une demande de renseignements complémentaires [0219] Selon une autre mode de réalisation, en dépendance de différents paramètres fournis conjointement à l'envoi du formulaire de validation en début de l’étape E4, le formulaire de validation n’est affiché qu’après acceptation de certaines conditions par rutilisateur.

[0220] Par exemple non exhaustif, si une restriction d'usage de la clé CL est associée à une zone géographique particulière, l'affichage dudit formulaire de validation est conditionné à l'acceptation par rutilisateur d'accéder à sa position géographique (activer la fonctionnalité de géolocalisation s'il s'agit d'un mobile,...). En cas de refus, le procédé s'arrête donc à cette étape.

[0221] En cas d'acceptation, les informations ainsi recueillies sont transmises en parallèle des données saisies sur le formulaire de validation.

[0222] En variante, l'appareil de certification demande une géolocalisation sur un terminal de l'utilisateur distinct physiquement du dispositif DC de génération de codes (ce second terminal ayant été relié à l'utilisateur durant la phase préalable EP (ou mis à jour plus tard, auprès de l’organisme de certification). Selon une autre variante, l’organisme de certification peut demander de façon aléatoire la géolocalisation du poste de l’utilisateur ou une autre preuve d'identité (empreinte,...), tout ceci étant conforme aux directives DSP2.

[0223] En variante, en cas de refus, ledit formulaire est affiché, mais aucune donnée associée n’est envoyée en fin de l’étape E4, ce qui provoque un refus de la demande au cours de l’étape E5.

[0224] Une fois le formulaire affiché à l'attention de l'utilisateur, ce dernier peut le remplir à l'aide du code CC issu de son dispositif DC associé à sa clé CL, selon les différentes variantes d'implémentations dudit dispositif DC détaillées à l'étape préalable.

[0225] Le code généré de manière dynamique

[0226] Le terme cryptogramme dynamique réfère pour sa définition de l'état de l'art aux codes dits cryptogramme à 3 chiffres visibles au dos des cartes bancaires du marché. Ledit code est composé de données (3 chiffres dans le cas des cartes bancaires) non incorporés dans la bande magnétique desdites cartes et permettant en les fournissant séparément de sécuriser une transaction.

[0227] La technologie des codes dynamiques limite un des principaux risques liés au piratage en ligne du numéro de carte et de son cryptogramme, en faisant varier celui-ci par période (demi-heures, heures ...) : un éventuel pirate ayant récupéré les différentes informations nécessaires au paiement sur internet (numéro de carte, date d’expiration et cryptogramme visuel) n'aura en effet que très peu de temps pour utiliser ces données avant que le cryptogramme ne devienne obsolète. Le procédé permettant de vérifier par la suite la validité dudit code est expliqué à l'étape E5.

[0228] Comment obtenir la 1 ^-version du code, CCI

[0229] Par exemple non exhaustif, selon l'implémentation la plus simple, l'utilisateur saisit le code CC actuellement affiché sur son dispositif DC.

[0230] Concrètement, dans l'état de la technique, des cartes bancaires à cryptogramme dynamique intègrent un écran e-paper (papier électronique) inséré dans l'épaisseur de cette carte, une mini-batterie pouvant durer 3 ans (durée de vie de ces cartes) et une antenne NEC. Le microcontrôleur impulsé par l’horloge, génère un cryptogramme toutes les demi-heures. Le code généré est ensuite envoyé vers l’écran LCD e-paper et reste affiché jusqu’au moment de la génération du prochain code afin de pouvoir être lu par l'utilisateur à tout moment.

[0231] Selon un autre exemple, l'utilisateur demande l'affichage du code CCI en appuyant sur un bouton poussoir de son dispositif DC, ou en scannant son empreinte sur ledit dispositif,... ce qui déclenche le calcul dudit code CCI par le dispositif DC, et son affichage consécutif sur la zone d'affichage dudit dispositif DC.

[0232] Plusieurs méthodes de génération de code sont possibles et il n'entre pas dans la présente demande de brevet de décrire ces méthodes. Il peut par exemple non exhaustif s'agir d'un procédé cryptogrammique prenant en compte plusieurs données comme un numéro de carte, un timestamp et un secret partagé entre la carte et l’émetteur, ou encore une liste de cryptogrammes précalculés intégrée dans la mémoire afin diminuer le coût de revient du dispositif.

[0233] Le dispositif DC peut être implémenté de diverses manières, non seulement sous forme de carte à cryptogramme dynamique, mais aussi inséré dans un dispositif dédié à la production de codes ou bien de manière dématérialisé, par exemple sous forme de logiciel, code ou appli téléchargé sur au moins un dispositif personnel DP de l'utilisateur tel que son PC ou son téléphone mobile, à condition que ledit dispositif dispose d'un 1^er sous moyen de génération des cryptogrammes CC selon les spécifications voulues, et d’un 2^ème sous moyen de présentation / affichage desdits cryptogrammes CC à l'utilisateur.

[0234] Selon un mode de réalisation préféré toutefois, ce dispositif est un dispositif séparé des moyens de connexion à Internet classique, et est fourni par l'appareil de certification au client. Par exemple non exhaustif, le dispositif DC incorporant des moyens de génération des cryptogrammes et de présentation / affichage peut ainsi être incorporé dans un support tel qu'une carte plastifiée, une montre, une bague un bracelet... ces types de support devant alors disposer d'un dispositif d'affichage permettant de visualiser le code cryptogrammique en cours. De tels objets ont comme principaux intérêts de pouvoir être toujours disponibles et accessibles par l'utilisateur, et ce de façon distincte des autres moyens d'interactions avec les services en ligne.

[0235] Le principe de fonctionnement est conforme à ceux de l'état de l'art déjà présenté ciavant.

[0236] Le code cryptogrammique généré peut être une suite de lettres et ou de chiffres, voire inclure quelques caractères spéciaux. Un des grands avantages de ce procédé, outre la sécurisation accrue des processus l'utilisant, consiste en la simplification côté utilisateur. Ce besoin de simplification favorise le choix de suites relativement courtes, par exemple entre 3 et 6 chiffres et/ou lettres successives, à l'instar des codes générés par les cartes bancaires à cryptogramme dynamique qui se limitent à une succession de 3 chiffres (cette limitation étant toutefois liée à la compatibilité avec les codes de confirmation à 3 chiffres des autres cartes bancaires).

[0237] Moyen de déclenchement

[0238] Selon une variante, l'affichage du code CC nécessite un moyen dit de déclenchement ou d'impulsion (appuyer sur un bouton par exemple) qui lance l'affichage du code.

[0239] Selon une autre variante, outre cet affichage, ledit moyen de déclenchement commande (déclenche) également la génération du code CC. L'intérêt de cette dernière variante est en plus de la variabilité périodique déjà évoquée ci avant (le code change toutes les demi-heures par exemple, même en présence du mécanisme de déclenchement) de disposer d'une variabilité aléatoire à l'initiative de l'utilisateur.

[0240] Cette variante implique le besoin d’assurer la synchronisation entre le code CCI généré par le dispositif DC à ce niveau et la seconde version CC2 du code généré lors de l’étape E5 au niveau des serveurs dudit appareil de certification sur un dispositif DCC pour cette clé CL. La problématique est donc que pour toute action (ex.

impulsion) déclenchant une génération d’un nouveau code CC, par le dispositif DC, le dispositif DCC doit être synchronisé, afin qu'à l’étape E5, la clé CC puisse être validée au niveau de l'appareil de certification.

[0241] Par exemple si la méthode de génération du code CC se base sur une liste ordonnée de cryptogrammes précalculés intégrée dans la mémoire du dispositif DC en regard de la clé CL, avec la même liste de cryptogrammes précalculés disponible au niveau du dispositif DCC en regard de la clé CL, une impulsion au niveau de DC fait passer au cryptogramme suivant de la liste côté utilisateur, et cette avancée doit être communiquée d'une façon ou d'une autre au niveau de DCC pour conserver la synchronisation. (Il n'y aurait, par contre, pas d'impact au niveau des autres changements de code CC selon la périodicité préprogrammée (toutes les demi-heures par exemple) : l'avancée dans les codes CC se fait alors (en complément des avancées par impulsion) de façon synchrone entre DC et DCC pour ladite clé CL.

[0242] Selon une l^ère variante, pour obtenir la synchronisation voulue, ledit dispositif DC est connecté d'une façon ou d'une autre au réseau Internet selon un des nombreux moyens connus, et ce afin de transmettre ladite information relative à l'impulsion (ou autre acte déclencheur) aux serveurs hébergeant le dispositif DCC. Cette l^ère variante comporte, outre les coûts et consommation en énergie des moyens de communication nécessaires au niveau de DC, des risques potentiels en termes de sécurité, puisqu'un chemin de connexion et d'authentification est nécessaire entre DC et DCC. En outre, un canal retour serait aussi nécessaire afin de vérifier l'acquittement de la bonne réception de l'impulsion au niveau de DCC.

[0243] Selon une 2ème variante, la synchronisation est gérée par un moyen spécifique à l'étape E5.

[0244] Selon une 3ème variante préférée plus évoluée, une suite de caractères inclus dans le code CC est réservée à la synchronisation due aux impulsions au niveau du dispositif DC. Par exemple non exhaustif, le code CC est composé de 6 caractères, les quatre premiers formant la clé cryptogrammique CCv, et les deux derniers formant un code CCs permettant lors de l’étape E5 au dispositif DCC de retrouver le nombre d'impulsions effectuées depuis la création de la clé CL. Cette variante sera décrite plus en détails en relation avec l’étape E5.

[0245] Ces deux dernières variantes permettent de s'affranchir d'impulsions non volontaires effectuées par l'utilisateur, ou d'impulsions non suivies de la mise en œuvre des étapes suivantes de notre procédé.

[0246] Selon une 4^ème variante, un période de temps minimale entre 2 impulsions est imposée, par exemple non exhaustif au maximum toutes les 3 secondes, cet intervalle pouvant être complété par un nombre maximum d'impulsions par unité de temps, par exemple non exhaustif un maximum de 5 impulsions par minutes et de 40 impulsions par heure. Ces limitations ont comme intérêt de limiter les impulsions en séries non souhaitées (par exemple pour éviter les problématiques liées à un mécanisme d'impulsion resté actif par erreur : ledit mécanisme peut être un bouton qui doit être enfoncé pour générer une impulsion, ou un masque recouvrant le moyen d'affichage, qui une fois ôté génère l'impulsion,...). Ces dernières données de limitation pourraient éventuellement être paramétrables par l'utilisateur pour une clé CL donnée.

[0247] Selon une 5^ème variante préférée, plusieurs clés CL utilisent le même dispositif DC de génération de code CC. Cette dernière variante, outre la simplicité d'usage qu'elle apporterait, présente le grand intérêt de complexifier encore plus la problématique des éventuels pirates.

[0248] La simplicité est alors évidente, puisque pour toute ces clés CL, ou pour un sousgroupe de ses clés CL, l'utilisateur n'a alors besoin d'interagir avec un seul dispositif générant et affichant les codes CC. Cette variante est possible puisque nous avons vu ci-avant qu'un utilisateur disposant d'un compte auprès de l'appareil de certification peut demander une ou plusieurs clés CL différentes, chacune pouvant être associée avec différents types d'informations pouvant être distinctes d'une clé à l'autre.

[0249] De nombreuses variantes d'implémentation sont possibles pour les moyens de déclenchement. Selon une de nos variantes préférées, l'impulsion est liée à un capteur d'empreinte intégré au dispositif DC, ce qui a comme avantage de permettre à notre procédé et système de réaliser une double authentification, procurant une augmentation de la sécurité et respectant la directive européenne DSP2, puisqu’outre la ressaisie du code, l'utilisateur doit s'authentifier via son empreinte digitale. Auquel cas, l'empreinte devrait être reconnue pour générer une impulsion. On peut ainsi envisager un dispositif incluant une bague à capteur d’empreinte : il suffit d'un mouvement de pouce vers la bague pour mettre la paume du pouce sur cette bague. Même en cas de vol de ladite bague, le dispositif DC ne pourrait donc pas être mis en œuvre ... Ces variantes ne sont pas limitées aux seuls capteurs d’empreintes ; d’autres types de capteurs biométriques peuvent être employés (ex. capteurs d’empreinte vocale, des dispositifs de scan d’iris).

[0250] La compatibilité du code CC avec les CW classiques

[0251] Remarque : Ces paragraphes se rapportent au cas particulier de l'usage de notre variante par rapport aux codes CW des cartes bancaires.

[0252] La problématique dans un tel cas de figure tient à la compatibilité nécessaire avec les procédés de paiement en ligne déjà en place, qui incorporent la saisie d'un code CW à 3 chiffres en regard des autres données de la carte bancaire (clé et date de péremption). Comme nous l'avons vu ci-dessus, les dispositifs DC utilisés selon les modes de réalisation de l’invention génèrent des codes CC qui ne sont pas nécessairement composés de successions de 3 chiffres, mais peuvent être une succession de par exemple 6 ou 8 chiffres et ou lettres. Auquel cas, par défaut, nos codes CC ne seraient pas compatibles avec les codes CW à 3 chiffres attendus pour une transaction bancaire.

[0253] Deux variantes permettent de résoudre cette problématique de compatibilité avec les systèmes normalisés déjà en place.

[0254] * La l^ère variante consiste à imposer que les 3 premiers caractères dudit code généré soient des chiffres. Il suffit pour cela d’adapter les méthodes de génération au niveau du dispositif DC et, côté appareil de certification, au niveau du dispositif DCC.

[0255] L'utilisateur lors d'une transaction bancaire classique doit se limiter à saisir ces 3 premiers chiffres, qui éventuellement sont affichés sur l’écran du dispositif DC de façon différenciés des autres caractères de la série (une autre couleur par exemple).

[0256] Bien que cette variante soit un peu plus compliquée à expliquer aux utilisateurs, et réduit le nombre de combinaisons disponibles, elle permet de répondre très simplement à la problématique.

[0257] * Une 2^ème variante, limitée aux dispositifs DC à impulsions, supprime ces 2 inconvénients. Selon cette variante, les méthodes de génération desdits codes CC comportent la possibilité de générer un code à 3 caractères de type chiffre selon un intervalle d'impulsions prédéterminé, par exemple toutes les 4 impulsions. Auquel cas, si le code CC courant affiché n'est pas à 3 chiffres, l'utilisateur lance une impulsion (et ce au maximum 3 fois consécutives), avant que s'affiche un code CC à 3 chiffres.

[0258] * Une 3ème variante mixe les 2 propositions ci-dessus : toutes les n impulsions, un code CC à n caractères (6 ou 8 par exemple) est généré, les 3 premiers caractères dudit code étant une succession de 3 chiffres, compatible avec les procédés utilisant des codes types CW donc.

[0259] A noter que les lère et 3^ème variantes peuvent nécessiter une adaptation au niveau de l’étape E5.

[0260] Quel que soit la manière dont la première version CCI du code est générée côté utilisateur, elle est ensuite transmise à l’appareil de certification. Selon un exemple non limitatif, l’utilisateur recopie le code CCI au niveau du formulaire de validation qui lui est présenté et valide ledit formulaire. La validation génère l’envoi du résultat de la validation, à savoir la communication dudit code CCI recopié associé à la clé CL, et éventuellement des données complémentaires associées, vers les moyens ad hoc de l'appareil de certification.

[0261] Pour assurer une authentification, le formulaire peut être combiné à des dispositifs tiers, tel que par exemple un dispositif de lecture d'empreinte, ou d'analyse d'iris, ou tout autre information spécifique de l'utilisateur et connue de l'appareil de certification (mot de passe, réponse à une question,...) dont les informations recueillies peuvent être transmises en parallèle à celles décrites ci-dessus en fin de l’étape E4.

La Cinquième Etape : E5

[0262] Le procédé s'achève alors par une 5^ème et dernière étape, E5, au cours de laquelle l'organisme de certification récupère puis compare la première version CCI du code CC, reçu du dispositif DC de l’utilisateur, à une seconde version CC2 générée au niveau des serveurs dudit organisme de certification pour ladite clé CL dudit utilisateur (ou acquise par l’organisme de certification par exemple depuis un dispositif DCC externe). L’appareil de certification compare les deux versions du code. Si les deux correspondent (ex. sont identiques), l’appareil de certification accepte la demande, sinon il la refuse. Dans tous les cas, une information indiquant le résultat de la comparaison est retournée au service SQ, éventuellement couplé aux informations complémentaires.

[0263] L'opération principale de cette étape E5 consiste à vérifier si la première version du code CC fourni du côté de l'utilisateur à la étape E4 est conforme à celui attendu. Il convient à cet effet que le serveur ou système incorporant les serveurs dudit organisme de certification soit en mesure de vérifier l'exactitude du cryptogramme indiqué par le présumé utilisateur à l'étape E4.

[0264] Pour cela, il convient au niveau de cet organisme de certification de disposer en regard de chaque clé CL d'un moyen et dispositif DCC permettant de produire ledit code CCS associé à CL (ou à un ensemble de clés CL selon la variante selon laquelle un seul couple de dispositifs DC et DCC est associé à plusieurs clés CL) à un instant donné.

[0265] Tout dépend à ce niveau de la méthode utilisée pour générer CC au niveau du dispositif DC de l'utilisateur, sachant que la même méthode devra alors être utilisée au niveau de DCC. Nous nous limitons ci-dessous aux deux exemples non exhaustifs de méthodes déjà citées lors de la description de l'étape EP :

[0266] Selon le 1^er exemple, une liste de cryptogrammes précalculés, avec une sélection de cryptogramme par pas de temps (par exemple toutes les heures on passe au code suivant dans ladite liste) est enregistrée dans une mémoire en regard de CL, la même liste de cryptogrammes précalculés devant également être disponible au niveau du dispositif DCC en regard de CL.

[0267] Selon le 2^ème exemple, un timestamp et un secret sont partagés entre le dispositif générateur de codes dynamiques et l’organisme de certification. Le serveur abritant le dispositif DCC pour ledit code CL doit alors être parfaitement synchronisé avec le serveur abritant le dispositif DC de l'utilisateur (afin de récupérer le même timestamp).

[0268] A noter que plusieurs méthodes peuvent être utilisées au niveau du dispositif de l'organisme de certification, sachant que seule une méthode sera implémentée pour une clé CL donnée.

[0269] Outre les méthodes, pour une clé CL donnée, les 2 dispositifs DC et DCC doivent être synchronisés.

[0270] Dans les cas d'implémentations simples du dispositif DC, cette synchronisation est effectuée au moment de la fabrication ou de la programmation des deux dispositifs DC et DCC et ne varie plus. Auquel cas, le dispositif DCC permet de recalculer le code CC2 associé à CL, puis le compare au code CCI communiqué en regard de la clé CL en fin de l’étape E4. Le résultat de cette comparaison est conservé pour la fin de l’étape E5.

[0271] Comme nous l'avons évoqué à l'occasion de l'étape EP, la problématique de synchronisation est plus complexe en cas de dispositif DC générant un code CC à l'aide d'un moyen d'impulsion (en appuyant sur un bouton par exemple), de façon isolé ou en complément de l'évolution par pas de temps ou autre (il n'y a pas de problématique particulière bien entendu si le moyen d'impulsion ne sert qu'à afficher le code courant (donc s'il ne sert qu'à économiser la batterie, ou dans les variantes selon lesquelles l'impulsion est liée à une empreinte ou autre paramètre biométrique, à sécuriser l'affichage).

[0272] Comme nous l'avons évoqué lors de la description de l'étape EP, une l^ère variante pour résoudre la problématique de synchronisation liée à la génération lors de l’étape E4 du code CC à l'aide d'un moyen d'impulsion quelconque au niveau du dispositif DC consiste en un moyen de gestion spécifique GS à l'occasion de l'étape E5.

[0273] La mise en œuvre dudit moyen GS consiste dans une l^ère sous étape à sauvegarder le code CC2-init et ses données respectives de synchronisation. Ces données de synchronisation dépendent de la méthode employée pour générer ledit code CC2-init relativement à la clé CL. Pour reprendre l'exemple d'une méthode basée sur une liste ordonnancée de cryptogrammes précalculés, il s'agirait de la position du code CC2-init dans ladite liste ordonnancée.

[0274] Au cours d'une seconde sous étape, le moyen GS génère le code suivant (CC2-init)+l pour ladite clé CL de façon classique à l'aide du dispositif DCC, puis compare ledit code (CC2-init)+l à celui CCI communiqué à l'issue de l'étape E4. Si lesdits code (CC2-init)+l et CCI ne correspondent pas, plutôt que de retourner directement une réponse négative à l'issue de l’étape E5, le moyen GS, lors de 3^ème sous étapes successives n, génère un code (CC2-init)+i (i=2, 3, ... ,n) et le compare à celui CCI communiqué à l'issue de l'étape E4, et ce jusqu'à ce qu'il trouve une correspondance.

[0275] Selon une variante, le nombre de sous étapes successives est limité, par exemple non exhaustif à la valeur 100. En conséquence, si au bout de n=100 3èmes sous-étapes successives aucune concordance avec CCI n'est trouvée, la comparaison sera considérée comme négative (soit mauvais code CCI, soit le dispositif DC est défaillant, ce qui du point de vue du traitement de la demande donne un résultat identique).

[0276] Au cours d'une 4^ème sous étape, si la comparaison est jugée négative, le moyen de gestion spécifique GS resynchronise le dispositif DCC pour la clé CL au niveau du code CC2-init.

[0277] Si la comparaison est jugée positive au cours de la 2^ème ou de l'une des 3^ème sous étapes successives, le moyen de gestion spécifique GS resynchronise le dispositif DCC pour la clé CL au niveau du code (CCS-init)+i pour lequel une correspondance a été trouvée. Le résultat de cette comparaison est conservé pour la fin de l’étape E5.

[0278] Comme nous l'avons évoqué lors de la description de la quatrième étape, une 2^ème variante pour résoudre la problématique de synchronisation liée à la génération du code CC, côté utilisateur, à l'aide d'un moyen d'impulsion quelconque au niveau du dispositif DC consiste en un sous code CCs intégré dans le code CC. Ce code CCs pourrait par exemple être constitué par une suite de 2, ou en variante de 3 caractères numériques ou alphanumériques (au-delà, le code deviendra long à ressaisir par l'utilisateur à l’étape E4 du procédé).

[0279] Selon une l^ère variante simplifiée, le code CCs est une simple suite d'un ordre chronologique prédéfini à partir d'un point de départ lors la création de la clé CL. Par exemple, une suite aurait comme point de départ le code J8v et la chronologie serait :

[0280] * Pour le 1^er caractère : Ordre alphabétique à partir du J (1^er caractère du point de départ) jusqu'à retour à I, puis ordre croissant à partir du 7 jusqu'à retour au 6, puis ordre alphabétique inverse à partir du s jusqu'à retour au t.

[0281] * Pour le 2^ème caractère : ordre décroissant à partir du 8 jusqu'à retour au 9...

[0282] Et ainsi de suite pour le 3^ème caractère.

[0283] Selon cette variante, ces informations sont également implémentées sur les dispositifs DC et DCC relativement à la clé CL lors de la création de ladite clé (ou lors de la création de la l^ère clé CL si lesdits dispositifs DC et DCC sont communs à plusieurs clés). Auquel cas, la resynchronisation est effectuée de façon similaire à celle indiquée pour la l^ère variante ci-avant à l'aide d'un moyen GS similaire, mais portant sur le code CCs.

[0284] Une telle implémentation permet de gérer environ 175 000 impulsions distinctes sur la base d'une suite de 3 caractères composée de chiffres ou de lettres, en excluant ceux pouvant prêter à confusion entre chiffres et lettres. Un contrôle permet toutefois de démultiplier cette capacité en détectant un retour au point de départ. Bien qu’il y ait une possibilité relativement élevée que l’utilisateur puisse aisément repérer la suite de codes CCs, le code CCv reste imprévisible.

[0285] En variante, ledit code CCs peut, de façon exactement similaire au code CCv, être géré par une des méthodes possibles pour générer le code CCs (deux méthodes distinctes peuvent être implémentées pour le code CCv et le code CCs). Auquel cas, la resynchronisation est effectuée de façon similaire à celle indiquée pour la l^ère variante ci-avant à l'aide d'un moyen GS similaire, mais portant sur le code CCs.

[0286] A noter que pour accroître la sécurité, les codes CCv et CCs peuvent être mixés lors de l'affichage sur les dispositifs DC et DCC. Par exemple pour une suite globale sur 6 caractères, le code CCv est affiché sur les 2^ème, 3^ème et 6^ème caractères, tandis que le code CCs est affiché sur les 1ers, 4^ème et 5^ème caractères. Cette information devant bien entendu être connue au niveau du dispositif DCC pour à la fois effectuer la resynchronisation et vérifier la concordance entre le code saisi à l’étape E4 et le code attendu.

[0287] Toujours par souci de sécurisation accrue, selon certains modes de réalisation, les codes CCs et CCv sont conservés sur 2 serveurs distincts, toujours relativement à une clé CL (ou un ensemble de clés CL) respective. Auquel cas, le moyen spécifique GS est mis en œuvre au niveau du serveur abritant la suite de code CCs couplé à CL, et une fois la synchronisation effectuée, le résultat est transmis au serveur conservant CCv pour contrôler CCv en regard de la même clé CL. Une fois la comparaison effectuée, le résultat de ladite comparaison est conservé pour la fin de l’étape E5.

[0288] Dans le cas d'un résultat de comparaison négatif, une information de refus d'opération ou de transaction est retournée au service SQ demandeur, charge à ce dernier d'en informer éventuellement l'utilisateur.

[0289] Dans le cas d'un résultat de comparaison positif, de multiples traitements particuliers peuvent en outre être effectués pour valider ou non l'opération.

[0290] Par exemple non exhaustif, une opération relative à un achat en ligne sera acceptée si le montant du crédit associé à la clé CL, éventuellement sur un créneau temporel défini au niveau de ladite clé CL, est compatible avec le montant de l'achat. Si tel n'est pas le cas, une information de refus d'opération ou de transaction est retournée au service SQ demandeur, charge à ce dernier d'en informer éventuellement l'utilisateur. Dans l'affirmative, ledit montant du crédit associé à CL est débité du montant de l'achat.

[0291] Selon un autre exemple non exhaustif, si une restriction d'usage de la clé CL est associée à une zone géographique particulière, un moyen dédié vérifie si les données de géolocalisation ont bien été communiquées en fin de l’étape E4 en complément du code CC saisi par l'utilisateur, et dans l'affirmative si elles correspondent à la zone de géolocalisation autorisée. Si tel n'est pas le cas, une information de refus d'opération ou de transaction est retournée au service SQ demandeur, charge à ce dernier d'en informer éventuellement l'utilisateur. Le moyen de vérification de la géolocalisation (ou d'une empreinte,...) peut être implémenté sur un autre terminal de l'utilisateur.

[0292] Comme la personne du métier le comprendra, de nombreux autres contrôles complémentaires sont possibles et ils ne sont pas tous détaillé ici par souci de concision.

[0293] Si l'ensemble des contrôles sont positifs, une information de validation (ou d'acceptation) d'opération ou de transaction est retournée au service SQ demandeur, charge à ce dernier d'en informer éventuellement l'utilisateur.

[0294] Selon une variante, outre cette information d'acceptation de validation, et en dépendance du type d'opération et des autorisations de divulgation associées à la clé CL, des informations complémentaires sont être communiquées par l'organisme de certi38 fication CERT au service SQ.

[0295] Par exemple, pour une création de compte et ou une connexion de compte, des données associées à ce compte telles que le nom ou alias, un prénom, un email,... associés à CL sont retournées à SQ. Un des avantages pour le service SQ est que même en cas de piratage des bases de données, un éventuel pirate n'a pas accès à ces données si SQ ne les a pas stockées lui-même. Il n’est pas nécessaire que ce service SQ fasse des déclarations auprès des organismes tels que le CNIL (pour « Commission Nationale de l’informatique et des Libertés ») vu que ce service ne conserve pas de données personnelles. Les impératifs liés à la RGPD (pour « Règlement Général sur la Protection des Données ».) sont aussi grandement simplifiés car les services SQ concernés qui ne stockent aucune donnée personnelle.

[0296] Selon un autre exemple, le montant du crédit restant sur le compte de l'utilisateur après l'opération est retourné au service SQ (par exemple si ce service SQ est un service financier et que l'opération était un virement ou autre).

[0297] La variété des informations complémentaires pouvant être éventuellement diffusées est très variée en dépendance des types d'opérations effectuées avec une clé CL et des autorisations de divulgation.

[0298] Lors des connexions ultérieures, l'utilisateur peut se connecter de façon classique à son compte (mail + passe par exemple), mais il recevra toujours une demande de validation par code crypto : à cet effet, SQ recherche la clé associée audit compte dans sa base de données, puis interroge l'organisme de certification (succession des étapes E2 à E4). De ce fait, si le service SQ s'assure de l'unicité de l'identifiant de l'utilisateur, celui-ci n'aurait même plus besoin d'un mot de passe, la saisie du code CC associé à sa clé étant alors suffisante.

[0299] En variante, l'utilisateur peut utiliser sa clé CL pour se connecter au compte (mais il lui faut s'en souvenir).

[0300] Les mêmes procédures peuvent être utilisées pour un paiement.

[0301] En référence à la figure 4, les étapes du procédé mis en œuvre au niveau d’un poste utilisateur selon un mode de réalisation de l’invention vont être décrites ci-dessous.

[0302] Le procédé comporte une première étape Ela qui, du point de vue du poste utilisateur, comporte une étape (E30a) de formulation d’une demande, par un utilisateur (U) associé à une clé (CL) émise par un organisme de certification, de mise en œuvre d’une opération auprès d’un appareil de prestataire de service. L’affectation de la clé CL à l’utilisateur peut se faire lors d’une étape préalable EP semblable à celle décrite ci-dessus. Ensuite, il y a une étape de réception (E60a), par le poste utilisateur, d’une demande de code dynamique, destinée à l’utilisateur associé à la clé (CL), cette demande étant transmise par l’appareil de l’organisme de certification. S’ensuit une étape de génération, par un dispositif générateur de codes dynamiques de l’utilisateur, d’une première version (CCI) du code dynamique (F70) et une étape de transmission de la première version (CCI) du code dynamique à l’appareil de certification (F80). En fin du procédé, il y a une étape de réception (Fl 10), depuis l’appareil de prestataire de service, d’un message confirmant la réalisation de l’opération demandée.

[0303] On peut considérer que l’étape F60a fait partie d’une étape E3a semblable à l’étape E3 décrite ci-dessus, et que l’étape Fl 10 fait partie d’une étape E5a semblable à l’étape E5 décrite ci-dessus. On comprend, donc, que les remarques et variantes exposés cidessus à propos des étapes EP, El et E3 à E5 s’appliquent en général aussi aux étapes EP, Ela, E3a, E4 et E5a de la figure 4.

[0304] En référence aux figures 5 à 7, des exemples des architectures des éléments principaux du système 1 de la figure 1, sont présentés. Les figures 5 à 7 représentent des modules fonctionnels adaptés pour construire le poste utilisateur 10, l’appareil 20 de prestataire de service et l’appareil 30 de certification, sachant qu’en réalité la fonctionnalité décrite est typiquement mis en œuvre à l’aide d’instructions d’un programme d’ordinateur plutôt qu’à l’aide de modules physiques. Par ailleurs, la personne du métier comprendra que le nombre de modules fonctionnels peut être différent de ceux représentés sur les figures 5 à 7. En d’autres termes, les fonctions de certains modules peuvent être distribués sur un nombre accru de modules et/ou un module unique peut cumuler les fonctions de plusieurs des modules représentés.

[0305] Dans le mode de réalisation décrit ici, le poste utilisateur 10 peut comporter les modules fonctionnels représentés à la figure 5. Selon cet exemple le poste utilisateur 10 comprend un dispositif 12 générateur de codes dynamiques, et un module 14 de transmission à un appareil de certification des codes produits par le dispositif 12 générateur de codes dynamiques. Le poste comporte aussi une interface utilisateur 15 via laquelle l’utilisateur peut formuler une demande de mise en œuvre d’une opération auprès d’un appareil de prestataire de service, un premier module 17a de réception destiné à recevoir une demande de code dynamique depuis l’appareil 30 de l’organisme de certification, et un deuxième module 17b de réception destiné à recevoir, depuis l’appareil de prestataire de service, un message confirmant la réalisation de l’opération demandée. Les premier et deuxième modules de réception 17a, 17b peuvent être intégrés dans un seul module comme il est représenté sur la figure 5.

[0306] Eventuellement le poste utilisateur 10 peut comporter un moyen d’actionnement 15a et un capteur 16 de données biométriques. Dans l’exemple représenté à la figure 5 le moyen d’actionnement 15a fait partie de l’interface utilisateur 15. Selon certains modes de réalisation le dispositif 12 générateur de codes dynamiques est configuré pour générer un nouveau code en réponse à une action de l’utilisateur, notamment l’actionnement du moyen d’actionnement 15a intégré à l’interface utilisateur 15. Le capteur 16 de données biométriques est agencé alors pour obtenir des données bio métriques de l’utilisateur lors de l’action de l’utilisateur qui déclenche la génération d’un nouveau code. Le module 14 de transmission de codes est alors configuré pour ne transmettre à l’appareil de certification de code valable que si le capteur 16 de données biométriques valident les données biométriques détectées lors de ladite action de rutilisateur.

[0307] Dans le mode de réalisation décrit ici, l’appareil 20 de prestataire de service peut comporter les modules fonctionnels représentés à la figure 6. Selon cet exemple l’appareil 20 de prestataire de service comprend un module 22 de réception d’une demande, par l’utilisateur U, de mise en œuvre d’une opération, un module 24 d’émission (vers l’appareil de certification) d’une requête de validation de l'opération demandée, ladite requête indiquant la clé CL associée à rutilisateur U, et un module 26 de mise en œuvre de l’opération demandée suite à la réception d’un signal de validation de la part de l’appareil de certification.

[0308] Dans le mode de réalisation décrit ici, l’appareil 30 de certification peut comporter les modules fonctionnels représentés à la figure 7. Selon cet exemple l’appareil 30 de certification comprend un module 34 d’émission d’une demande de code dynamique, destinée à un dispositif générateur de codes dynamiques affecté à rutilisateur associé à ladite clé (CL). L’appareil 30 de certification comprend aussi un module 35 de réception de la première version CCI du code dynamique générée par le dispositif générateur de codes dynamiques GC côté utilisateur, un module 37 d’acquisition de la seconde version CC2 du code dynamique, un module 38 de comparaison des première et seconde versions CCI, CC2 du code dynamique, et un module 39 de transmission d’un signal de validation à l’appareil 20 de prestataire de service lorsque les première et seconde versions (CC1,CC2) du code dynamique correspondent. Le module 37 d’acquisition de la seconde version CC2 du code dynamique peut correspondre à un dispositif GCC générateur de codes dynamiques. L’appareil de certification peut comprendre aussi un module 32 de récupération des données de rutilisateur associée à la clé CL reçu de l’appareil de prestataire de service, destiné par exemple à récupérer les données de contrôle évoquées ci-dessus.

[0309] Comme nous l’avons indiqué ci-dessus, dans un mode particulier de réalisation, les différentes étapes du procédé de sécurisation sont déterminées par des instructions de programmes d’ordinateurs destinés à être mis en œuvre dans l’appareil de prestataire de service, dans l’appareil de certification et dans un poste utilisateur, ou plus généralement dans un ordinateur. Typiquement de tels ordinateurs comprennent les éléments représentés à la figure 8, c’est-à-dire un processeur CPU, une interface de communication I/O, une mémoire morte ROM, une mémoire vive RAM et un module DISP gérant l’affichage au niveau d’un écran (non représenté), ces composants étant reliés classiquement via un bus. Bien entendu d’autres composants classiques peuvent également être présents.

[0310] On comprendra que diverses modifications peuvent être apportées aux modes de réalisation décrits ci-dessus sans sortir du cadre de l’invention.

[0311] Par exemple, selon un mode particulier de réalisation de l’invention, l'étape El du procédé n’est pas réalisée. Le dispositif SQ initie le procédé dès la 2^ème étape E2 en demandant la validation d'une opération. Cette variante peut être illustrée dans de nombreux cas d'usage, dont par exemple non exhaustif celui d'un système anti-spam, qu'il soit SMS, mail, ou téléphonique. Auquel cas, ledit service SQ ne dispose pas des coordonnées du client, mais seulement de la clé CL à laquelle sont associées éventuellement différents moyens de contacter le client (par exemple le client accepte d'être contacté par mail et SMS, mais les coordonnées correspondantes ne sont pas fournies), et éventuellement, si futilisateur a autorisé les divulgations correspondantes à l'étape préalable, pour chaque moyen, des créneaux et/ou un nombre de contacts maximum par créneau.

[0312] Un exemple du procédé mis en œuvre par un système anti-spam selon un mode de réalisation de l’invention est maintenant décrit en référence à la figure 9.

[0313] Selon l’exemple de la figure 9, le prestataire de service SQ initie le procédé en demandant (E35) à l’appareil de certification la transmission d’un message à l’utilisateur U associé à une clé CL (par exemple un contact par mail). La demande REQ_OP du prestataire de service SQ est émise par l’appareil 20 de prestataire de service et identifie la clé CL de l’utilisateur visée. On peut considérer que cette étape E35 correspond à une variante E2b de l’étape E2 décrite ci-dessus. Lors d’une variante E3b de l’étape E3 décrite ci-dessus, l’appareil de certification 30 récupère (E50b) des données concernant l’utilisateur associé à la clé CL fourni par l’appareil de prestataire de service, par exemple des données identifiant les coordonnées de l’utilisateur et des données de contrôle que l’on peut caractériser de paramètres anti-spam.

[0314] L'organisme de certification CERT vérifie si la transmission du message à l’utilisateur selon la demande du prestataire de service SQ est ou non conforme aux paramètres anti-spam associés à l’utilisateur associé à la clé CL. Par exemple, l’organisme de certification vérifie si le service SQ fait partie des services autorisés figurant dans une liste d’autorisations de diffusion que l'utilisateur a indiqué à l'étape préalable en regard de la clé CL concernée, ainsi que les conditions éventuellement liées (nombre d'appels et ou de SMS / mails,... par période,...). Le procédé suit son cours et passe directement de l’étape E3b à une étape E5b, sans diffuser de formulaire de validation à futilisateur en fin de l’étape E3b. Dans le cas d’une détermination positive par l’appareil de certification, l'organisme de certification accepte la diffusion, et un mail / SMS ... TX_MES est envoyé / rerouté en respectant l'anonymat de futilisateur (ElOOb).

[0315] Une mise en forme minimale des mails, SMS ..., peut être réalisée. Par exemple l’appareil de prestataire de service peut demander au service de certification de commencer un message par les variables Prénom puis Nom selon une formulation prédéfinie au niveau de ΓΑΡΙ concernée et, si l’appareil de certification accepte de transmettre le message à l’utilisateur l’appareil de certification remplace les variables Prénom puis Nom par les données correspondantes (si elles sont détenues).

[0316] Selon une variante de ce mode de réalisation, si le service SQ n'est pas inclus dans la liste des autorisations de diffusion, l'organisme de certification CERT transmet une demande spécifique à l’utilisateur recherchant l’accord de celui-ci pour ajouter le prestataire de service SQ à la liste des services autorisés à lui envoyer des messages. A cette fin, l’appareil de certification envoie (F60b) un formulaire de validation TX_FRM en fin de l’étape E3b et une variante E4b de l’étape E4 est réalisée. Auquel cas, l'utilisateur lors de l’étape E4b, peut soit valider, sur le formulaire, la demande d'ajout du service SQ à la liste des services autorisés en saisissant un code confidentiel CC, soit la refuser. Le poste utilisateur transmet sa réponse U_ REP à l’appareil de certification (F80b). L’étape E5b se déroule normalement, avec selon les réponses de l’étape E4b un ajout de SQ dans les autorisations de diffusion liées à CL et la diffusion correspondante, soit un refus de diffusion.

[0317] En variante de ce mode de réalisation, le formulaire de validation à l’étape E4b inclut une saisie optionnelle d'informations complémentaires, du type : autorisations permanentes, sur un créneau ou des créneaux prédéfinis, nombres de contacts acceptés,.... En outre, l’utilisateur peut comme déjà indiqué pour l'étape préalable, à tout moment sur son compte sur l'organisme de certification modifier pour sa clé CL les autorisations, dont celles de diffusion, données ou non au service SQ concerné.

[0318] Dans la description ci-dessus de certains modes de réalisation de l’invention certains remarques se réfèrent à la transmission de la clé CL depuis l’appareil de prestataire de service à l’appareil de certification. Il convient de rappeler que le message de l’appareil de prestataire de service peut transiter via un organisme tiers OT.

Claims (1)

1. Revendications [Revendication 1] Procédé de sécurisation d’opérations, caractérisé en ce qu’il comprend : une étape (F30a) de formulation d’une demande, par un utilisateur (U) associé à une clé (CL) émise par un organisme de certification, de mise en œuvre d’une opération auprès d’un appareil (20) de prestataire de service ; une étape (L60a) de réception, par un poste utilisateur, d’une demande de code dynamique, destinée à l’utilisateur associé à la clé (CL), émise par un appareil (30) de l’organisme de certification ; une étape (L70) de génération, par un dispositif (12) générateur de codes dynamiques associé à la clé (CL) de l’utilisateur, d’une première version (CCI) du code dynamique une étape (L80) de transmission de la première version (CCI) du code dynamique à l’appareil (30) de certification ; et une étape (L110) de réception, en provenance de l’appareil de prestataire de service, d’un message confirmant la réalisation de l’opération demandée, à condition que la première version (CCI) du code dynamique corresponde à une deuxième version du code dynamique générée au niveau de l’organisme de certification. [Revendication 2] Procédé de sécurisation d’opérations selon la revendication 1, caractérisé en ce que la génération de la première version (CCI) du code dynamique par le dispositif générateur de codes dynamiques est déclenchée par une action de l’utilisateur. [Revendication 3] Procédé de sécurisation d’opérations selon la revendication 2, caractérisé en ce que des données biométriques de l’utilisateur sont détectées lors de l’action de l’utilisateur qui déclenche la génération d’un code, et l’étape (L80) de transmission de la première version (CCI) du code dynamique à l’appareil (30) de certification n’a lieu que si les données biométriques détectées sont validées. [Revendication 4] Procédé de sécurisation d’opérations selon l’une quelconque des revendications 1 à 3, caractérisé en ce que le code dynamique comporte un sous-code (CCs) et l’évolution du code dynamique comporte un changement progressif de chaque caractère du sous-code selon une règle respective. [Revendication 5] Procédé de sécurisation d’opérations selon la revendication 4, caractérisé en ce que les caractères du sous-code sont distribués parmi les autres caractères du code dynamique.

   [Revendication 6] Poste utilisateur (10) caractérisé en ce qu’il comprend : une interface utilisateur (15) configurée pour permettre à un utilisateur (U) associé à une clé (CL) émise par un organisme de certification de formuler une demande de mise en œuvre d’une opération auprès d’un appareil (20) de prestataire de service ; un premier module (17a) de réception destiné à recevoir une demande de code dynamique, destinée à l’utilisateur associé à la clé (CL), depuis un appareil (30) de l’organisme de certification ; un module (14) de transmission à l’appareil de certification d’une première version de code dynamique générée par un dispositif générateur de codes dynamiques associé à la clé (CL) de l’utilisateur ; et un deuxième module (17b) de réception destiné à recevoir, depuis l’appareil de prestataire de service, un message confirmant la réalisation de l’opération demandée à condition que la première version (CCI) du code dynamique corresponde à une deuxième version du code dynamique générée au niveau de l’organisme de certification. [Revendication 7] Poste utilisateur selon la revendication 6, caractérisé en ce qu’il comprend : un module d’actionnement (15a) destiné à être actionné par l’utilisateur pour déclencher la génération d’un code par le dispositif générateur de codes dynamiques, et un capteur (16) de données biométriques ; dans lequel le capteur (16) de données biométriques est agencé pour obtenir des données biométriques de l’utilisateur lors de l’actionnement du module d’actionnement (15a) par l’utilisateur, et le module (14) de transmission de codes est configuré pour ne transmettre à l’appareil de certification la première version de code que si les données biométriques détectées par le capteur (16) de données biométriques lors dudit actionnement du module d’actionnement (15a) par l’utilisateur sont valides. [Revendication 8] Système de sécurisation d’opérations, caractérisé en ce qu’il comprend un appareil (20) de prestataire de service et un appareil (30) de certification, dans lequel : l’appareil (20) de prestataire de service comprend : un module (22) de réception d’une demande, par un utilisateur (U), de mise en œuvre d’une opération, un module (24) d’émission vers l’appareil de certification d’une requête

   [Revendication 9] de validation de l’opération demandée, ladite requête indiquant une clé (CL) associée à l’utilisateur (U), et un module (26) de mise en œuvre de l’opération demandée suite à la réception d’un signal de validation de la part de l’appareil de certification ; et l’appareil (30) de certification comprend :

   un module (34) d’émission d’une demande de code dynamique, destinée à l’utilisateur associé à ladite clé (CL), un module (35) de réception d’une première version (CCI) du code dynamique générée par un dispositif générateur de codes dynamiques affecté à l’utilisateur associé à ladite clé (CL), un module (37) d’acquisition d’une seconde version (CC2) du code dynamique, un module (38) de comparaison des première et seconde versions (CC1,CC2) du code dynamique, et un module (39) de transmission d’un signal indiquant la validation de l’opération lorsque les première et seconde versions (CC1,CC2) du code dynamique correspondent.

   Procédé de sécurisation d’opérations, caractérisé en ce qu’il comprend : une étape (F30) de demande, par un utilisateur (U), de mise en œuvre d’une opération auprès d’un appareil (20) de prestataire de service ;

   une étape (F40) d’émission par l’appareil (20) de prestataire de service à un appareil (30) de certification d’une requête de validation de l’opération demandée, ladite requête indiquant une clé (CL) associée à l’utilisateur (U) ;

   une étape (F60) d’émission d’une demande de code dynamique, destinée à l’utilisateur associé à la clé (CL), depuis l’appareil (30) de certification ;

   une étape (F70) de génération, par un dispositif (12) générateur de codes dynamiques affecté à l’utilisateur associé à ladite clé (CL), d’une première version (CCI) du code dynamique ;

   une étape (F80) de transmission de la première version (CCI) du code dynamique à l’appareil (30) de certification ;

   une étape (F90) d’acquisition d’une seconde version (CC2) du code dynamique et de comparaison des première et seconde versions du code dynamique par l’appareil (30) de certification ; et à condition que les première et seconde versions (CC1,CC2) du code dynamique correspondent, une étape (F100) de transmission par

   l’appareil (30) de certification à l’appareil (20) de prestataire de service, d’un signal indiquant la validation de l’opération demandée par l’utilisateur (U). [Revendication 10] Procédé de sécurisation d’opérations selon la revendication 9, caractérisé en ce que : l’étape (F40) d’émission de la requête de validation d’opération comprend l’émission d’une requête comportant des informations concernant l’opération demandée, et le procédé comprend une étape (F50) de récupération des données de l’utilisateur associée à la clé (CL), cette étape de récupération de données comprenant : la récupération de données de contrôle indiquant au moins une restriction par rapport aux opérations permises, et l’analyse des informations reçues concernant l’opération demandée pour déterminer si cette opération est ou non permise par rapport aux données de contrôle. [Revendication 11] Procédé de sécurisation d’opérations selon la revendication 10, caractérisé en ce que : l’étape de récupération de données de contrôle comprend la récupération de données définissant au moins une restriction choisie dans le groupe consistant en : le type d’opération permise, la période temporelle pendant laquelle des opérations sont permises, la zone géographique où, ou à partir de laquelle, des opérations sont permises, le prestataire de service auprès duquel des opérations sont permises, et le prix associé à la réalisation de l’opération. [Revendication 12] Procédé de sécurisation d’opérations selon la revendication 11, caractérisé en ce qu’il comprend en outre une étape de paramétrage par l’utilisateur des restrictions définies par les données de contrôle. [Revendication 13] Procédé informatisé de sécurisation d’opérations selon l’une quelconque des revendications 9 à 12, caractérisé en ce qu’il comprend, si les première et seconde versions (CC1,CC2) du code dynamique ne correspondent pas l’appareil (30) de certification, une étape de mise en œuvre d’un processus itératif consistant à acquérir une nouvelle version du code dynamique, à comparer la nouvelle version avec la première version (CCI) du code dynamique, et à répéter les étapes du processus itératif tant que le résultat de la comparaison est négatif et jusqu’à ce

   qu’un nombre n de versions du code aient été acquises et comparées avec la première version du code.

   [Revendication 14] Procédé de sécurisation d’opérations selon l’une quelconque des revendications 9 à 13, caractérisé en ce que l’étape (F60) d’émission d’une demande de code dynamique par l’appareil (30) de certification comprend la transmission à un poste de l’utilisateur d’une demande de renseignements complémentaires et la validation de l’opération par l’appareil (30) de certification est conditionnée par les renseignements complémentaires fournis par le poste utilisateur.

   [Revendication 15] Procédé de sécurisation d’opérations selon la revendication 10, caractérisé en ce que :

   la demande (REQ_OP) de mise en œuvre d’une opération est formulée par l’appareil de prestataire de service et comprend une demande de transmission d’un message à l’utilisateur associé à la clé (CL) ;

   l’étape (E50b) de récupération des données de l’utilisateur associée à la clé (CL), par l’appareil (30) de certification, comprend la récupération de données de contrôle indiquant des paramètres anti-spam de l’utilisateur et la récupération de coordonnées de l’utilisateur ;

   les étapes d’émission de demande de code dynamique et de génération des première et seconde versions du code dynamique sont omises ; et l’étape (ElOOb) de transmission du signal de validation de l’opération demandée comprend la transmission du message (TX_ MES) à l’utilisateur selon les coordonnées récupérées par l’appareil de certification lorsque l’appareil de certification constate que la transmission du message est compatible avec les paramètres anti-spam de l’utilisateur.