[go: up one dir, main page]

FR3041195A1 - Procede d'acces a un service en ligne au moyen d'un microcircuit securise et de jetons de securite restreignant l'utilisation de ces jetons a leur detenteur legitime - Google Patents

Procede d'acces a un service en ligne au moyen d'un microcircuit securise et de jetons de securite restreignant l'utilisation de ces jetons a leur detenteur legitime Download PDF

Info

Publication number
FR3041195A1
FR3041195A1 FR1501894A FR1501894A FR3041195A1 FR 3041195 A1 FR3041195 A1 FR 3041195A1 FR 1501894 A FR1501894 A FR 1501894A FR 1501894 A FR1501894 A FR 1501894A FR 3041195 A1 FR3041195 A1 FR 3041195A1
Authority
FR
France
Prior art keywords
server
microcircuit
token
secure
secure microcircuit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
FR1501894A
Other languages
English (en)
Inventor
Denis Pinkas
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Dp Security Consulting
Original Assignee
Dp Security Consulting
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Dp Security Consulting filed Critical Dp Security Consulting
Priority to FR1501894A priority Critical patent/FR3041195A1/fr
Priority to PCT/EP2016/071386 priority patent/WO2017042375A1/fr
Priority to PCT/EP2016/076261 priority patent/WO2017042400A1/fr
Publication of FR3041195A1 publication Critical patent/FR3041195A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/42—Anonymization, e.g. involving pseudonyms

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)

Abstract

Procédé permettant, à partir d'une application cliente, d'accéder à un serveur cible en ligne au moyen d'un microcircuit sécurisé, d'un pseudonyme et d'un jeton de sécurité contenant des attributs, ledit jeton ayant été obtenu auprès d'un serveur producteur de jetons, qui peut être soit un fournisseur d'attributs, soit un fournisseur d'identité, caractérisé par le fait que l'application cliente obtenant le jeton est dans l'impossibilité de pouvoir octroyer le bénéfice dudit jeton de sécurité à une autre application cliente, et que le procédé comprend les étapes suivantes: - la mise à disposition des utilisateurs par des fabricants de microcircuits de microcircuits sécurisés aux caractéristiques particulières, - la création d'un compte sur un serveur cible au moyen d'un pseudonyme et d'un tel microcircuit sécurisé, - la création d'un compte sur un serveur producteur de jetons au moyen d'un pseudonyme et d'un tel microcircuit sécurisé, - la demande d'un jeton de sécurité auprès d'un serveur producteur de jetons au moyen d'un pseudonyme et d'un tel microcircuit sécurisé, - la génération d'un jeton de sécurité par le serveur producteur de jetons, et - l'acceptation du jeton de sécurité par le serveur cible.

Description

Description Domaine technique
La présente invention se rapporte à un dispositif permettant d'accéder à un service en ligne au moyen de pseudonymes et d'attributs contenus dans des jetons de sécurité.
Le procédé concerne particulièrement l’accès à un serveur via un réseau, par exemple via le réseau Internet, par une entité informatique appelée "application cliente", qui peut représenter une personne physique ou une personne morale, dans le paradigme "client-serveur".
Technique antérieure Généralement, l'accès d'un client à un serveur est conditionné par la présentation de certains "attributs" de l'utilisateur qui, à défaut de son identité complète, révèlent certaines données personnelles de cette personne. A titre d'exemple, il y a des situations où il est souhaitable de pouvoir démontrer que l'on est majeur (plus de 18 ans), sans pour autant devoir révéler sa date de naissance, son nom ou son prénom. L'accès à un serveur au moyen de la présentation d'attributs est parfois connu sous l’acronyme anglais ABC: "Attribute Based Credentials".
En matière de sécurité, on a longtemps considéré qu'il n'y avait que deux sortes de personnes: les personnes utilisatrices d'un système situées à l'intérieur de ce système et les attaquants situés à l'extérieur de ce système. Si cette vision a été utile et reste toujours utile, elle n'est pas suffisante.
De nombreux systèmes ont été décrits dans la littérature et certains sont en cours d'expérimentation avec le concours financier de la Commission Européenne. Ces systèmes font l'hypothèse que les utilisateurs sont toujours "honnêtes". Hélas, cette hypothèse ne résiste pas dans la vie courante.
En effet, il faut aussi considérer des personnes utilisatrices d'un système situées "à l'intérieur de ce système" qui accepteraient de collaborer ensemble durant quelques instants afin que l'une des personnes qui serait en mesure de démontrer à un serveur une qualité qu'elle possède (par exemple qu'elle est majeure) puisse transférer cette qualité à une autre personne qui ne la possède pas (par exemple parce qu'elle est mineure) afin que cette autre personne soit alors en mesure de démontrer à un serveur une qualité qu'elle ne possède pas.
Quelle que soit la sophistication des algorithmes cryptographiques mis en œuvre, il est strictement impossible avec une solution ne mettant en œuvre que du logiciel d'empêcher le transfert d'une qualité d’une personne qui la possède au profit d'une personne qui ne la possède pas. D'où la nécessité de mettre en œuvre un composant matériel, en la circonstance un microcircuit sécurisé, aussi connu sous l'appellation "élément sécurisé" (en anglais "secure element"), tel qu'une carte à microcircuit ou un module de sécurité. Certains systèmes qui ont été décrits dans la littérature et qui sont en cours d'expérimentation permettent de mettre en œuvre un microcircuit.
Cependant la manière dont ce microcircuit sécurisé est mis en œuvre ne permet pas d'empêcher le transfert d'une qualité (c'est à dire d'un attribut) depuis la personne qui la possède vers une personne qui ne la possède pas.
Parmi différentes solutions proposées, on connaît le projet ABC4Trust qui fédère deux solutions: la solution "U Prove" de Microsoft et la solution "Identity Mixer" (IdeMix) d'IBM Zürich. Même avec la mise en œuvre d'un microcircuit sécurisé, du moins telle que décrite dans la documentation accessible au public en mai 2015, aucune de ces deux solutions ne permet pas d'empêcher le transfert d'une qualité depuis la personne qui la possède vers une personne qui ne la possède pas.
Par ailleurs, le groupe de travail 16 (WG 16) du TC 224 du Comité Européen de Normalisation (CEN) a élaboré en avril 2015 un document de 372 pages découpé en 5 parties qui est intitulé : "Application Interface for secure éléments used as Qualified electronic Signature (Seal-) Création Devices". Ce document qui décrit la mise en œuvre de "secure éléments" décrit des protocoles de sécurité - et non des interfaces applicatives comme son titre l'identique à tort - et différents services de sécurité n ayant aucun rapport avec son titre. Le document comporte cinq parties.
La partie 4, intitulée : "Privacy spécifie Protocols" permet, après 28 échanges, de supporter un mécanisme d'authentification par pseudonymes appelé "Restricted identification , qui est décrit dans la section 3.3. Elle permet aussi de transférer des attributs, après un total de 45 échanges.
Ce mécanisme outre sa lourdeur et sa complexité nécessite la mise en œuvre d'un architecture spécifique qui nécessite de déployer au niveau des serveurs des certificats vérifiables par des cartes à microcircuit (appelé CV certificates pour "Card Vérifiable certificate") en sus des certificats X.509 qui servent à établir des liaisons du type HTTPS. Le principe de base retenu est d'effectuer tous les échanges sensibles avec la carte à microcircuit au moyen de canaux sécurisés (secure channels) ce qui ne permet pas de modifier les échanges sans que cela ne soit détecté; mais ce qui ne permet pas à l'utilisateur de voir le contenu des échanges effectués par sa carte avec le monde extérieur. L'un des principes de base du respect de la vie privée dès la conception ("privacy by design" en anglais) n'est dès lors pas respecté: l'utilisateur n'a pas la possibilité de donner son accord pour autoriser le transfert de chaque attribut: il doit faire confiance aux droits qui sont contenus dans un "CV certificate" et ne peut les modifier.
Les droits sont fixes ce qui est contraire aux principes de base du respect de la vie privée dès la conception d'autant qu'ils sont définis par une autorité que l'utilisateur ne connaît pas. Le contenu d'un CV certificate est très difficile à interpréter car il contient un champ spécifique appelé CHAT (Certificate Hôlder Authorization Template) qui contient un identifiant d'objet et une suite de bits qui est fonction de cet identifiant. La manière dont cette carte à microcircuit est mise en œuvre permet cependant d'empêcher le transfert d'une qualité depuis la personne qui la possède vers une personne qui ne la possède pas au prix du déploiement d'une architecture très lourde et de protocoles très complexes.
Des précisions complémentaires ont été apportées lors d'un exposé effectué à l'occasion de l'atelier de sécurité tenu par l'ETSI à Sophia Antipolis le 24 juin 2015 sous le titre : "elD and the principle of privacy by design".
La présentation est accessible sur le site de l'ETSI à l'adresse suivante : http://docbox.etsi.org/Workshop/2015/201506_SECURITYWEEK/ elDAS_THREAD/S03_elD/DPSECURITYCONSULTING_PINKAS.pdf Résumé de l'invention L’invention a pour but de proposer un procédé plus simple permettant de sécuriser l’accès à un serveur sans qu’aucun attribut personnel certifié ne puisse être transféré depuis une personne qui le possède vers une personne qui ne le possède pas. L'invention permet le déploiement de solutions du type "Attribute Based Credentials" (ABC) qui étaient en cours d'étude au sein du comité ISO SC 27 WG 5, en septembre 2015.
Ainsi, dans le cadre de cette invention, on doit impérativement utiliser un microcircuit sécurisé, tel que celui que l'on peut trouver dans une "carte à microcircuit" ("smart card" en anglais). Un tel microcircuit sécurisé devra être mis en œuvre ou bien par une personne physique, ou bien par une personne morale ou bien par une entité informatique appelée "application cliente" ("Client Application" en anglais, abréviation CA), dans le paradigme "client-serveur".
Cette "application cliente" peut aussi être une applet de confiance fonctionnant dans un navigateur, par exemple une applet Java.
Le terme "microcircuit sécurisé" sera utilisé ci-après par commodité pour désigner tout composant physique sécurisé capable de résister à des attaques physiques et logiques et à même d'exécuter un ensemble de fonctions mettant en œuvre à la fois des données internes protégées et des données externes fournies par l'environnement du microcircuit selon des exigences précises. Ce terme recouvre aussi les composants du type TPM (Trusted Platform Module) que l'on trouve dans certains ordinateurs professionnels et UICC (Universal Integrated Circuit Card) normalisé par le 3GPP (3rd Génération Mobile System) et l'ETSI (European Télécommunications Standards Institute). Le dernier terme "à la mode" en anglais est maintenant "secure element". Sa traduction française "élément sécurisé" est cependant encore peu utilisée. L'invention s'appuie sur les concepts définis dans les spécifications techniques de l'Alliance FIDO (Fast Identity On line) qui sont disponibles à l'adresse suivante: https://fidoalliance.org/specifications/download
Plus exactement sur les protocoles décrits dans le cadre d'authentification universel (Universal Authentication Framework - UAF). Les protocoles décrits dans cette spécification permettent une authentification à l'aide de pseudonymes en utilisant un pseudonyme différent pour chaque serveur. Seulement, les protocoles décrits dans les documents de FIDO ne prévoient pas et ne permettent pas la présentation d'attributs certifiés. L'invention permet d'étendre l'architecture de FIDO et les protocoles de FIDO pour permettre le transfert d'attributs certifiés vers un serveur tout en respectant le principe du respect de la vie privée dès la conception ("privacy by design" en anglais).
Plusieurs modes d’exécution de l'invention seront décrits ci-après, à titre d’exemples non limitatifs, en référence aux dessins annexés dans lesquels : - la Figure 1 illustre schématiquement l'architecture FIDO d'origine, - la Figure 2 illustre schématiquement l'architecture FIDO complétée selon l'invention, et - la Figure 3 illustre les données essentielles contenues dans un microcircuit sécurisé selon l'invention. L’invention est un procédé permettant, à partir d’une application cliente (10), d'accéder à un serveur en ligne (11) ("Service Provider" en anglais, abréviation SP) au moyen d'un microcircuit sécurisé (12), d'un pseudonyme et d'un jeton de sécurité contenant des attributs, ledit jeton ayant été obtenu auprès d'un serveur producteur de jetons (13), abréviation SPJ, caractérisé par le fait que l'application cliente (10) est dans l'impossibilité de pouvoir octroyer le bénéfice dudit jeton de sécurité à une autre application cliente, et que le procédé comprend les étapes suivantes: - la mise à disposition des utilisateurs par des fabricants de microcircuits de microcircuits sécurisés aux caractéristiques particulières, - la création d'un compte sur un serveur cible au moyen d'un pseudonyme et d'un tel microcircuit sécurisé, - la création d'un compte sur un serveur producteur de jetons au moyen d'un pseudonyme et d'un tel microcircuit sécurisé, - la demande d'un jeton de sécurité auprès d'un serveur producteur de jetons au moyen d'un pseudonyme et d'un tel microcircuit sécurisé, - la génération d'un jeton de sécurité par le serveur producteur de jetons, - l'acceptation du jeton de sécurité par le serveur cible. L'invention est caractérisée par le fait que chaque microcircuit sécurisé objet du procédé est livré par son fournisseur avec : - d'une part, une Information Publique (14) (abréviation IP) contenue dans le microcircuit sécurisé permettant de savoir ou de déduire que l'octroi de ladite information publique a été conditionné par le respect des exigences de sécurité et de fonctionnalités applicables au microcircuit sécurisé et décrites dans le cadre de ladite invention, et - d'autre part, une clé privée (15) (abréviation CP) associée qui sera utilisée impérativement pour effectuer certaines opérations précises, de manière telle que les signatures numériques effectués en utilisant ladite clé privée soient vérifiables à partir de ladite information publique, et où l'Information Publique (14) contient au moins une information permettant de savoir, par le biais d'un contact à un serveur, si une donnée publique spécifique au microcircuit sécurisé est toujours valide (fonctionnement en liste blanche) ou bien a été invalidée (fonctionnement en liste noire).
Selon une réalisation préférée, chaque microcircuit sécurisé (12) est livré par son fournisseur avec : - un certificat de clé publique, et, - une clé privée associée, où la clé privée et la clé publique constituent une paire unique, et où le certificat de clé publique qui constitue l'Information Publique (14) contient au moins une information permettant de savoir, par le biais d'un contact à un serveur, si une donnée publique spécifique au microcircuit sécurisé est toujours valide (fonctionnement en liste blanche) ou bien a été invalidée (fonctionnement en liste noire).
Selon une autre réalisation, chaque microcircuit sécurisé (12) est livré par son fournisseur avec : - une Information Publique (14) contenant une donnée publique propre au microcircuit sécurisé, un identifiant du fournisseur de microcircuits, ainsi qu'une clé publique commune à un ensemble de microcircuits produits par ledit fournisseur de microcircuits, et - une Clé Privée (15) propre au microcircuit, calculée par le ledit fournisseur de microcircuits à partir d'une clé privée unique gardée secrète par ledit fournisseur de microcircuits, et où l'Information Publique (14) contient au moins une information permettant de savoir, par le biais d'un contact à un serveur, si une donnée publique spécifique au microcircuit sécurisé est toujours valide (fonctionnement en liste blanche) ou bien a été invalidée (fonctionnement en liste noire). L'invention est caractérisée en ce que le microcircuit sécurisé (12) génère à la demande de l'application cliente les données permettant de mettre en œuvre la création d'un compte sur un fournisseur de service donné ou sur un serveur producteur de jetons donné au moyen d'un pseudonyme, la demande de l'application cliente étant accompagnée au minimum du paramètre suivant: - un identifiant IdS du serveur objet de la demande, tandis qu'en retour, et si l'identifiant procuré par l'application cliente n'est pas déjà présent dans le microcircuit sécurisé, ledit microcircuit : - génère un pseudonyme Ps, qui est une valeur aléatoire de taille suffisante vis à vis du nombre d'utilisateurs potentiellement authentifiables sur le serveur pour que la probabilité qu'il puisse exister une collision entre pseudonymes soit quasiment nulle, et - génère une bi-clé (i.e. une paire de clés, c'est à dire une clé privée et une clé publique), puis, après l'accord de l'utilisateur légitime du microcircuit sécurisé (12), fournit des donnés permettant l'authentification vis à vis du serveur cible en signant numériquement à l'aide de la clé privée générée ci-dessus au minimum les données suivantes: (a) le pseudonyme généré par le microcircuit sécurisé pour ce serveur, (b) la valeur de la clé publique générée le microcircuit sécurisé pour ce serveur, et mémorise dans une entrée (16) du microcircuit sécurisé les informations suivantes: - l'identifiant du serveur IdS (17), - le pseudonyme généré Ps (18) de manière aléatoire pour ce serveur, - la clé privée Cp (19) correspondant à la bi-clé générée précédemment par le microcircuit sécurisé (12) pour ce serveur, et est aussi en mesure de mémoriser, associée à chaque entrée, de manière non restrictive, ni exhaustive d'autres informations (20) telles que : - une date de création de ladite entrée (si celle-ci est fournie par l'application cliente), - une date de dernière utilisation de ladite entrée (si celle-ci est fournie par l'application cliente). L'invention est caractérisée en ce que le microcircuit sécurisé (12) fournit à la demande de l'application cliente (10) les données permettant de mettre en œuvre la création d'un compte sur un serveur producteur de jetons donné au moyen d'un pseudonyme (18), tout en apportant simultanément au serveur la preuve qu'un microcircuit sécurisé (12) conforme aux exigences décrites dans le cadre de ladite invention est utilisé, la demande de l'application cliente étant accompagnée au minimum du paramètre suivant: - un identifiant du serveur producteur de jetons objet de la demande, tandis qu'en retour, et si l'identifiant procuré par l'application cliente n'est pas déjà présent dans le microcircuit sécurisé, ledit microcircuit : - génère un pseudonyme (18), qui est une valeur aléatoire de taille suffisante vis à vis du nombre d'utilisateurs potentiellement authentifiables sur le serveur pour que la probabilité qu'il puisse exister une collision entre pseudonymes soit quasiment nulle, et - génère une bi-clé (i.e. une paire de clés: l'une privée et l'autre publique), puis, après l'accord de l'utilisateur légitime du microcircuit sécurisé, fournit des donnés permettant l'authentification vis à vis du serveur cible en fournissant et en signant numériquement à l'aide de la clé privée (19) générée ci-dessus au minimum les données suivantes: (a) le pseudonyme (18) généré par le microcircuit sécurisé (12) pour ce serveur producteur de jetons, (b) la valeur de la clé publique générée le microcircuit sécurisé pour ce serveur producteur de jetons, et en plaçant cette signature numérique dans un champ (c), et de surcroît en signant numériquement à l'aide de la clé privé propre au microcircuit sécurisé (15) : - la signature numérique précédente présente dans le champ (c) ou bien les données (a) et (b), ainsi que l'information publique (14) propre au microcircuit sécurisé, qui est placée dans un champ (d), et place cette seconde signature numérique dans un champ (e), et mémorise dans une entrée (16) les informations suivantes: - un identifiant du serveur producteur de jetons (17), - le pseudonyme (18) généré de manière aléatoire pour ce serveur producteur de jetons, - la clé privée (19) correspondant à la bi-clé générée précédemment par le microcircuit sécurisé pour ce serveur producteur de jetons, et - optionnellement, un indicateur précisant que l'entrée a été créée selon cette procédure n° 2 dans la mesure où l'application appelante ne désire pas mémoriser cet indicateur, et est aussi en mesure de mémoriser, associée à chaque entrée, de manière non restrictive, ni exhaustive : - une date de création de ladite entrée (si celle-ci est fournie par l'application cliente), - une date de dernière utilisation de ladite entrée (si celle-ci est fournie par l'application cliente), étant entendu que ladite procédure n° 2 ne doit en aucun cas être utilisée par l'application cliente vis à vis d'un fournisseur de service (11). L'invention est caractérisée par le fait qu'une demande de jeton de sécurité adressée au microcircuit sécurisé (12) par l'application appelante (10) à l'intention d'un serveur producteur de jetons effectuée selon la procédure n° 3 décrite ci-dessous, ne peut être générée par le microcircuit sécurisé (12) qu'à partir du moment où il existe au moins déjà deux entrées (16) dans le microcircuit sécurisé, la première désignant un serveur cible, c'est à dire le serveur pour lequel le jeton est destiné, la seconde désignant un serveur producteur de jetons dont l'entrée a été créée selon la procédure n° 2, et dans ce cas, l'application cliente (10) doit fournir au microcircuit sécurisé les éléments suivants: (a) un défi ou un nombre unique, afin de pouvoir détecter des cas de rejeu, (b) les types d'attributs et/ou les valeurs d'attributs que l'application cliente souhaite voir incorporés dans le jeton de sécurité, (c) une période de validité des attributs (pour un jeton multi sessions) ou un champ vide ou absent (pour un jeton mono session), (d) une suite d'octets représentative du serveur cible, (e) un pointeur relatif à une entrée située dans le microcircuit sécurisé désignant le désignant le serveur cible, (f) un pointeur relatif à une entrée située dans le microcircuit sécurisé désignant le serveur producteur de jetons, tandis qu'en retour, le microcircuit sécurisé, après l'accord de l'utilisateur légitime du microcircuit sécurisé, produit un message formaté qui comporte : (a) le défi ou le nombre unique, (b) les attributs demandés par l'utilisateur, (c) une période de validité des attributs (pour un jeton multi sessions) ou un champ vide ou absent (pour un jeton mono session), (d) la suite d'octets représentative du serveur cible, (e) le pseudonyme contenu dans l'entrée pointée par le paramètre (e) de la commande, (f) le pseudonyme contenu dans l'entrée pointée par le paramètre (f) de la commande, (g) une signature numérique appliquée sur l'ensemble des données précédentes, au moyen de la clé privée relative au serveur producteur de jetons. L'invention est caractérisée par le fait qu'une demande de jeton de sécurité adressée au microcircuit sécurisé (12) par l'application appelante (10) à l'intention d'un serveur producteur de jetons (13), effectuée selon la procédure n° 4 décrite ci-dessous, ne peut être générée par le microcircuit sécurisé (12) qu'à partir du moment où il existe au moins déjà deux entrées (16) dans le microcircuit sécurisé, la première désignant un serveur cible, c'est à dire le serveur pour lequel le jeton est destiné, la seconde désignant un serveur producteur de jetons dont l'entrée n'a pas été créée selon la procédure n° 2, et dans ce cas, l'application cliente (10) doit fournir au microcircuit sécurisé les éléments suivants: (a) un défi ou un nombre unique, afin de pouvoir détecter des cas de rejeu, (b) les types d'attributs et/ou les valeurs d’attributs que l'application cliente souhaite voir incorporés dans le jeton de sécurité, (c) une période de validité des attributs (pour un jeton multi sessions) ou un champ vide ou absent (pour un jeton mono session), (d) une suite d'octets représentative du serveur cible, (e) un pointeur relatif à une entrée située dans le microcircuit sécurisé désignant le serveur cible, (f) un pointeur relatif à une entrée située dans le microcircuit sécurisé désignant le serveur producteur de jetons, tandis qu'en retour, le microcircuit sécurisé (12), après l'accord de l'utilisateur légitime du microcircuit sécurisé, produit un message formaté qui comporte : (a) le défi ou le nombre unique, (b) les attributs demandés par l'utilisateur, (c) une période de validité des attributs (pour un jeton multi sessions) ou un champ vide ou absent (pour un jeton mono session), (d) la suite d'octets représentative du serveur cible, (e) le pseudonyme contenu dans l'entrée pointée par le paramètre (e) de la commande, (f) le pseudonyme contenu dans l'entrée pointée par le paramètre (f) de la commande, (g) une signature numérique appliquée sur l'ensemble des données précédentes, au moyen de la clé privée relative au serveur producteur de jetons, (h) l'information publique propre au microcircuit sécurisé, (i) une signature numérique appliquée sur l'ensemble des données précédentes, au moyen de la clé privée propre au microcircuit sécurisé. L'invention est caractérisée par le fait que le microcircuit sécurisé (12) formate chaque champ de ses réponses signées de manière non ambigüe et que les données utilisées pour réaliser ce formatage font elles-mêmes parties des données signées de sorte qu'aucune opération ne peut, d'un point de vue fonctionnel, être confondue avec une autre opération et qu'en conséquence chacune d'entre elles peut être identifiée de manière non ambigüe et que les valeurs utilisées pour cette identification font partie des données signées, et que si des opérations supplémentaires devaient être mises en oeuvre par le microcircuit sécurisé, en aucun cas une réponse à l'une quelconque de ces opérations supplémentaires, à partir du moment où elle est signée, ne devra pouvoir être confondue avec une autre réponse signée et tout particulièrement avec les réponses signées du microcircuit sécurisé suite à des demandes de jeton telles qu'effectuées au moyen des procédures n° 3 et n° 4. L'invention est caractérisée par le fait qu'un jeton de sécurité émis par un serveur producteur de jetons (13) suite à une demande signée en provenance d'un microcircuit sécurisé (12) comporte, pour désigner le propriétaire du jeton, un champ contenant le pseudonyme d'un propriétaire déjà connu du serveur cible et que, du fait du processus menant à son incorporation dans le jeton, ce pseudonyme ne peut avoir été généré que par un microcircuit sécurisé (12) au moyen d'un générateur pseudo aléatoire et qu'en conséquence sa valeur ne pourra avoir été librement choisie par quiconque. L invention est caractérisée par le fait qu'un jeton de sécurité émis par un serveur producteur de jetons (13), suite à une demande signée en provenance d'un microcircuit sécurisé (12), comporte pour désigner le serveur cible auquel le jeton est destiné, une suite d'octets qui n'est pas interprétable par le serveur producteur de jetons (13), car cette suite d'octets est d'abord localement calculée par I application cliente (10) en utilisant une fonction de hachage et deux paramètres en entrée: une valeur de salage ("sait value" en anglais) et un identifiant du serveur cible, puis communiquée au serveur producteur de jetons en tant que paramètre de la demande afin d'être incorporée dans le jeton et en conséquence lorsque I application cliente communique au serveur cible concomitamment avec le jeton, cet identifiant et cette valeur de salage, ce dernier peut, grâce à ces deux valeurs, se reconnaître puis combiner ces deux valeurs à l'aide de la fonction de hachage pour retrouver la suite d'octets représentative présente dans le jeton de telle sorte que le serveur cible peut vérifier que le jeton de sécurité lui est effectivement destiné. L'invention est caractérisée en ce que l’accord de l'utilisateur légitime du microcircuit sécurisé est obtenu: (a) soit par la présentation d'un code PIN (Personal Identification Number) par le propriétaire légitime du microcircuit sécurisé qui est nécessaire pour autoriser certaines opérations liées à l'identification ou à l'authentification; ce code PIN étant appelé en la circonstance un "elD-PIN", (b) soit par la comparaison par le microcircuit sécurisé d'une donnée biométrique propre à l'utilisateur légitime du microcircuit sécurisé qui est nécessaire pour autoriser certaines opérations liées à l'authentification, (c) soit par une combinatoire d'un elD-PIN et d'une donnée biométrique propre à l'utilisateur légitime du microcircuit sécurisé. L'invention est caractérisée par le fait que le microcircuit sécurisé utilisé dans le cadre du procédé doit avoir les propriétés habituelles d'un "module de sécurité" ("security module" en anglais) ou d'un élément sécurisé ("secure element" en anglais) au sens des règles de l'art, et en particulier, une résistance aux attaques physiques externes, une résistance aux attaques cryptographiques différentielles, l'impossibilité de pouvoir dupliquer le contenu du microcircuit sécurisé si celui-ci ne l'autorise pas, et de surcroît, doit contenir les données décrites précédemment, doit supporter la procédure n°1, doit supporter la procédure n° 3 s'il supporte la procédure n° 2, doit supporter la procédure n° 4 s'il supporte pas la procédure n° 2 et doit être conforme aux exigences spécifiées dans le paragraphe précédent. L'invention est caractérisée en ce qu'un serveur producteur de jetons (13) n'acceptera d'émettre un jeton de sécurité suite à une demande de jeton pour un utilisateur identifié sous un pseudonyme donné que s'il est en mesure de vérifier que: (1) il ne s'agit pas du rejeu d'une demande de jeton, soit en contrôlant que le défi correspond bien à celui qui a été envoyé, soit en contrôlant que le nombre unique se trouve dans la fourchette de temps autorisé et que ce nombre unique ne figure pas déjà parmi les nombres uniques mémorisés durant cette fourchette de temps, (2) le pseudonyme désignant le serveur producteur de jetons dans la demande de jeton lui est connu, (3) le compte attaché à ce pseudonyme n'est ni temporairement, ni définitivement invalidé, (4) la demande de jeton est effectivement signée par la clé privée associée au compte, (5) l'information publique correspondant à la clé privée du microcircuit sécurisé qui a été mise en œuvre lors de l'ouverture du compte ou bien au plus tard lors de la demande du jeton est toujours valide ou bien n'est ni expirée, ni révoquée, (6) l'information publique a bien été émise par une autorité de confiance qui ne délivre une telle information qu'après s'être assuré que le microcircuit sécurisé répond à un cahier des charges précis lui permettant de savoir que toutes les exigences de sécurité applicables au microcircuit sécurisé sont respectées. L'invention est caractérisée par le fait qu'un serveur cible n'acceptera d'associer, après les vérifications d'usage, à un compte ouvert sous un pseudonyme les attributs contenus dans un jeton de sécurité, que si un compte a déjà été ouvert sur ce serveur sous le pseudonyme contenu dans le champ ad-hoc du jeton de sécurité, que si ce compte n'est ni temporairement, ni définitivement invalidé, que si la date à laquelle le jeton a été émis est voisine du temps présent ou bien si une période de validité est indiquée dans le jeton, si le temps présent est inclus dans cette période de validité, que si le serveur cible se reconnaît en tant que destinataire du jeton et que si le jeton de sécurité a été signé par un serveur producteur de jetons connu du serveur cible pour effectuer l'ensemble des vérifications prescrites au paragraphe précédent.
Comme illustré à la Figure 1, l'architecture de FIDO comprend une application cliente (10) et un fournisseur de service (11). Un compte doit être systématiquement créé sur le serveur du fournisseur de service, préalablement à tout accès.
Alors que FIDO autorise plusieurs variantes et n'impose en rien l'usage de microcircuits, l'invention impose l'usage de microcircuits et en particulier des deux exigences suivantes : a) le pseudonyme utilisé sur un fournisseur de service (11) ne peut être que généré par un microcircuit sécurisé (12) respectant l'ensemble des critères définis dans le procédé, et b) la bi-clé d'authentification associée à ce pseudonyme pour ce fournisseur de service (11) ne peut être que générée par un microcircuit sécurisé (12) respectant l'ensemble des critères définis dans le procédé.
De la sorte, ni l'utilisateur, ni le fournisseur de service (11) n'ont la possibilité de choisir le pseudonyme qui va être utilisé sur un fournisseur de service (11), ni d'avoir la connaissance de la clé privée associée à ce pseudonyme et à ce fournisseur de service (11), car cette dernière réside exclusivement dans le microcircuit sécurisé (12). Si l'utilisateur a l'usage de la clé privée, il n'a pas la connaissance de la valeur de la clé privée.
Comme illustré à la Figure 2, dans une structure selon l'invention, l'architecture initiale de FIDO est étendue en ajoutant deux composants : 1) un fournisseur d’attributs (21) ("Attribute Provider" en anglais), et 2) un fournisseur d’identité (22) ("Identity Provider" en anglais).
On utilisera le terme "serveur producteur de jetons" (13) pour désigner soit un fournisseur d'identité (22), soit un fournisseur d'attributs (21).
Dans l’exemple illustré, il n’est représenté qu’un seul fournisseur d’identité, qu'un seul fournisseur d’attributs et qu'un seul fournisseur de service. Cependant, pour une même application cliente, il pourra y avoir plusieurs serveurs pour chaque type.
Un fournisseur d’identité (22), tout comme un fournisseur d’attributs (21), est en mesure d'émettre des jetons de sécurité ("security tokens" en anglais). Un jeton de sécurité est un train de bits ou d'octets qui est numériquement signé par un fournisseur d’identité (22) ou par un fournisseur d’attributs (21) et qui contient notamment un ou plusieurs attributs relatifs à une personne (ou à une entité).
On dit alors que ces attributs sont "certifiés" par le fournisseur d’identité (22) ou par le fournisseur d’attributs (21).
La différence entre un fournisseur d’identité (22) et un fournisseur d’attributs (21) dépend essentiellement de la nature des attributs qui sont délivrés.
Un fournisseur d’identité (22) délivre principalement des attributs du type: nom, prénom, date de naissance, lieu de naissance, toutes ces informations ayant été généralement collectées et vérifiées soit à partir de documents d'identité nationaux sous forme papier, soit à partir de documents d'identité nationaux sous forme électronique.
Un fournisseur d’attributs (21) peut délivrer tout type d'attribut, à savoir des attributs d'identité et/ou des attributs, par exemple du type: "Membre du club de golf de Saint-Nom-la-Bretèche" ou bien "Diplômé d'un DEA de Physique de l'Université Paris VI; Option "Théorie des jeux", mais aussi des attributs du type nom, prénom, date de naissance, lieu de naissance, lieu de résidence, etc..
Un fournisseur d'attributs (21) pourra, dans certains cas, exiger la présentation d'un jeton de sécurité émis par un fournisseur d'identité (22) avant d'accepter d'émettre un jeton de sécurité.
La Figure 1 indique un dialogue D1 (23) entre l'application cliente (10) et le fournisseur de service (11),
La Figure 2 mentionne trois types de dialogues: - un dialogue D1 (23) entre l'application cliente (10) et le fournisseur de service 11, - un dialogue D2 (24) entre l'application cliente (10) et le fournisseur d’attributs (21), et - un dialogue D3 (25) entre l'application cliente (10) et le fournisseur d’identité (22),
Selon les trois cas (A, B et C) décrits ci-dessous, deux ou trois dialogues sont mis en oeuvre.
Cas A. L'application cliente (10) contacte directement le fournisseur d’attributs (21) au moyen du dialogue D2 (24) afin d’obtenir un jeton de sécurité, puis contacte le fournisseur de service (11) au moyen du dialogue D1 (23) afin de le lui transmettre.
Cas B. L'application cliente (10) contacte directement le fournisseur d’identité (22) au moyen du dialogue D3 (25) afin d'obtenir un jeton de sécurité, puis contacte le fournisseur de service (11) au moyen du dialogue D1 (23) afin de le lui transmettre.
Cas C. L'application cliente 10) contacte d’abord le fournisseur d’identité (22) au moyen du dialogue D3 (25) afin d'obtenir un jeton de sécurité, puis contacte le fournisseur d’attributs (21) au moyen du dialogue D2 (24) afin de le lui transmettre, reçoit en retour un autre jeton de sécurité et contacte enfin le fournisseur de service (11) au moyen du dialogue D1 (23) afin de lui transmettre le second jeton de sécurité.
La suite du document utilisera l'expression "serveur cible" pour désigner un serveur auquel un jeton est destiné. Un serveur cible sera habituellement un fournisseur de service (10), mais pourra aussi être un fournisseur d’attributs (21) lorsqu'un jeton de sécurité en provenance d'un fournisseur d'identité lui sera présenté.
Dans l’exemple illustré, les échanges pour ces trois dialogues seront de préférence effectués en mode HTTPS (ou équivalent) afin de que le contenu des échanges ne soit pas compréhensible au monde extérieur et que toute modification ou rejeu d'un échange puisse être détecté.
Avant de pouvoir demander un jeton à un serveur producteur de jetons, l'application cliente (10) doit préalablement créer un compte sur ce serveur producteur de jetons à l'aide du microcircuit sécurisé (12).
Avant de pouvoir présenter un jeton à un serveur cible, l'application cliente (10) doit préalablement créer un compte sur le serveur cible à l'aide du microcircuit sécurisé (12).
La création de ces comptes devra de préférence être effectuée au travers d'une liaison en mode HTTPS (ou équivalent) afin que l'application cliente située sur le poste de travail de l'utilisateur puisse avoir l'assurance d'être en liaison avec le "bon serveur". L’application cliente (10) peut alors s'adresser à un serveur producteur de jetons afin d'obtenir un jeton de sécurité (13) qui va contenir un ou plusieurs attributs et qui sera ensuite présenté à un serveur cible. Selon les attributs contenus dans le jeton, l'accès sera ensuite autorisé ou non par le serveur cible. L'invention impose la Règle 1 suivante aux serveurs producteurs de jetons : un serveur producteur de jetons (13) n'acceptera d'émettre un jeton de sécurité à un utilisateur que s'il est en mesure d'obtenir l'assurance que le jeton de sécurité qui est demandé l'a été suite à la demande d'un utilisateur qui utilise un microcircuit sécurisé (12) qui possède des caractéristiques qui font l'objet du procédé. L'invention impose la Règle 2 suivante aux serveurs cibles : un serveur cible n'acceptera un jeton de sécurité de la part d'un serveur producteur de jetons (13) que s'il est en mesure d'obtenir l'assurance que le jeton de sécurité qui a été généré par ce serveur producteur de jetons (13) ne l'a été que suite à la demande d'un utilisateur qui utilise un microcircuit sécurisé (12) qui possède toutes les caractéristiques qui font l'objet du procédé.
Dans les exemples illustrés par les Figures 2 et 3, le dispositif est une carte à microcircuit ICC ("Integrated Circuit Card" en anglais). La création d'un compte sur un serveur producteur de jetons (13) étant un préalable, il suffit de prouver une fois et une seule fois auprès d'un tel serveur qu'un microcircuit sécurisé qui possède toutes les caractéristiques qui font l'objet du procédé est mis en œuvre par l’utilisateur connu du serveur producteur de jetons (13) sous un pseudonyme donné. De manière optimum, la démonstration de la mise en œuvre d'un microcircuit sécurisé possédant toutes les caractéristiques requises par le procédé sera ainsi effectuée lors de la création du compte sur le serveur producteur de jetons (13). Cependant, cela peut aussi être fait lors de la première demande de jeton de sécurité, ou encore, lors de chaque demande de jeton de sécurité (ce qui serait alors non optimum, mais techniquement possible).
Ainsi, aucun jeton de sécurité ne sera délivré par un serveur producteur de jetons (13), si l'utilisateur n'est pas en mesure de démontrer lors de la création du compte, ou à défaut lors de lors de la première demande de jeton ou encore à défaut lors de chaque demande de jeton qu'il utilise un dispositif physique qui possède d'une part toutes les caractéristiques générales d'un microcircuit sécurisé, en particulier : résistance aux attaques physiques externes, résistance aux attaques cryptographiques différentielles, impossibilité de dupliquer le contenu d'un microcircuit si le microcircuit n'autorise pas l'accès à certains contenus; et d'autre part des caractéristiques particulières complémentaires, indispensables au bon fonctionnement du procédé. Celles-ci seront détaillées ci-après.
Le fait que l'utilisateur utilise un microcircuit sécurisé donné (par exemple, identifiable par un numéro de série) devra être démontré à un serveur producteur de jetons (13), mais surtout pas à un fournisseur de service (11 ).
En effet, si une telle démonstration était faite, elle pourrait révéler un identifiant spécifique au microcircuit sécurisé, ce qui pourrait permettre aux fournisseurs de service d'établir des liens entre leurs utilisateurs, ce qui est contraire à l'un des principes du respect de la vie privée.
Le fournisseur de service (11) obtiendra de son côté une assurance indirecte du fait que l'utilisateur qui utilise effectivement un microcircuit sécurisé qui possède toutes les caractéristiques qui font l'objet du procédé. En effet, le fournisseur de service (11) n'accordera sa confiance qu'aux serveurs producteurs de jetons (13) qui lui garantissent effectuer cette vérification.
Chaque microcircuit (12) sécurisé doit comporter : - une information publique (14), permettant de vérifier les données signées avec la clé privée propre à ce microcircuit, et - une clé privée (15) qui lui est propre.
Cela est illustré sur la Figure 3. L'information publique permet de savoir directement ou indirectement que son octroi a été conditionné par l'assurance que le microcircuit sécurisé (12) répond aux exigences imposées au microcircuit du fait du procédé, par exemple, en émettant un certificat de clé publique sous une Politique de Certification (PC) donnée.
Un microcircuit sécurisé (12) conforme aux exigences du procédé devra de préférence être certifié par un organisme indépendant en fonction d'un cahier d'exigences établi sous la forme d'un Profil de Protection (PP) et avec un niveau d'assurance "élevé", par exemple "EAL4+". Le résultat de la certification pourra être remis au fabriquant du microcircuit qui pourra alors s'en prévaloir.
Chaque fabriquant de microcircuit produisant des microcircuits sécurisés conformes aux exigences du procédé devra s'assurer que l'Information Publique (14) contenue dans le microcircuit sécurisé (12) contient au moins une information permettant de savoir, par le biais d'un contact à un serveur, si une donnée publique spécifique au microcircuit sécurisé est toujours valide ou bien a été invalidée.
Lors de l'ouverture d'un compte sur un fournisseur de service (11) ou sur un serveur producteur de jetons (13), le microcircuit sécurisé (12) doit être en mesure de générer deux données et de les associer à un identifiant de serveur IdS (17), comme illustré sur la Figure 3 : - un pseudonyme Ps (18), qui est une valeur aléatoire de taille suffisante pour éviter toute collision entre pseudonymes sur le serveur en question et qui doit impérativement être généré par le microcircuit, et, - une bi-clé (i.e. une paire de clés: i.e. une clé privée Cp (19) et une clé publique) qui doit impérativement être générée par le microcircuit. Dès lors que l'utilisateur souhaite disposer de plus d'un compte sur le même serveur, un index peut être ajouté.
Les éléments ci-dessus sont alors mis en œuvre pour réaliser une authentification et une fois celle-ci réussie, le microcircuit mémorise de manière permanente au niveau d'une "entrée" (16), au minimum, les trois informations suivantes: - un identifiant du serveur distant IdS (17), le pseudonyme Ps (18) généré de manière aléatoire pour ce serveur distant, - la clé privée Cp (19) correspondant à la bi-clé générée précédemment pour ce serveur distant par le microcircuit. D'autres informations (20) peuvent être ajoutées. En particulier, afin de mieux gérer l'obsolescence et la suppression des entrées qui ne sont plus utilisées, chaque entrée pourra en outre comporter : - la date de création de l'entrée, et/ou - la date de la dernière utilisation de l'entrée.
Afin d'optimiser le fonctionnement, l'application cliente (10) peut demander que la clé privée (15) propre au microcircuit sécurisé (12) ainsi que l'information publique (14) permettant de vérifier les données signées avec la clé privée (15) propre à ce microcircuit sécurisé (12) soit mise en œuvre lors de l'authentification. Si cela est le cas, cette particularité peut être mémorisée par le microcircuit sécurisé (12) afin que l'application cliente (10) puisse en tenir compte et d'éviter de refaire cette même demande lors d'une autre authentification.
Naturellement, l'application cliente dispose d'une commande permettant, après l'accord de l'utilisateur, la suppression d'une ou plusieurs entrées (16).
Afin d'optimiser les gestion des entrées (16), l’application cliente pourra aussi avoir un intérêt à fournir au microcircuit un indicateur complémentaire lui permettant de faire la différence entre une entrée relative à un fournisseur de service (11) et une entrée relative à un serveur producteur de jetons (13). Si cela est le cas, l'indicateur sera mémorisé par le microcircuit sécurisé (12) dans l'entrée (16) en tant que donnée complémentaire (20) en question.
On va maintenant examiner la structure d'un jeton de sécurité.
Selon le procédé objet de l'invention, un jeton de sécurité émis par un serveur producteur de jetons et destiné à un serveur cible comportera au minimum les informations suivantes : (a) le bénéficiaire du jeton, sous la forme d'un pseudonyme de l'utilisateur tel qu'il est connu du serveur cible, (b) un ou plusieurs attributs de l'utilisateur, (c) un identifiant non ambigu du serveur producteur de jetons, par exemple, un certificat du type X.509, (d) pour un jeton multi sessions, une période de validité du jeton de sécurité éventuellement associée à un champ permettant de vérifier l'état de révocation de ce jeton ; ou, pour un jeton mono session, le temps où le jeton a été émis, usuellement un temps UTC (Universal Coordinated Time), (e) un numéro d'identification unique du jeton attribué par le serveur producteur de jetons, (f) le serveur cible auquel le jeton est destiné, sous la forme d'une suite d'octets ne permettant qu'au serveur cible de se reconnaître, (g) une signature numérique des valeurs précédentes à l'aide de la clé privée du serveur producteur de jetons.
Le champ (a) permet au serveur cible de savoir au bénéfice duquel pseudonyme le jeton a été généré. Si le pseudonyme n'est pas reconnu, le jeton de sécurité doit être rejeté par le serveur cible.
Le champ (b) permet au serveur cible de connaître les attributs certifiés tels qu'émis par un serveur d'identité (22) ou par un serveur d’attributs (21).
Le champ (c) permet de s'assurer de l'identité du signataire du jeton de sécurité.
Le champ (d) permet de délivrer des jetons de sécurité mono session ou multi sessions. Ainsi : - Pour un jeton de sécurité mono session, les attributs présents dans le jeton ne seront conservés par le fournisseur de service (11) que durant une seule ouverture de session. Toute session a une durée limitée, avec un délai de fin de session ("time-out") en cas d'inactivité prolongée. - Pour un jeton de sécurité multi sessions, les attributs présents dans le jeton seront conservés par le fournisseur de service (11) durant une période de validité définie dans le jeton. Si cette période de validité est considérée comme étant "assez longue" par le serveur d’identité (22) ou par le serveur d’attributs (21), ce dernier pourra mettre en oeuvre un mécanisme de révocation qui permettra de révoquer tous les attributs contenus dans le jeton.
Le champ (e) permet d'identifier le numéro de jeton de sécurité dans le but de le révoquer, par exemple, à l'aide d'un mécanisme du type CRL (Certificate Révocation List) ou du type OCSP (On-line Certificate Status Protocol). Le champ (e) permet aussi d'identifier de manière unique, en particulier à des fins d'audit, un jeton émis un serveur producteur de jetons.
Le champ (f) permet de cibler le jeton de sécurité pour un serveur cible donné, sans pour autant permettre l'identification de ce serveur par le serveur producteur de jetons. Pour ce faire, avant de demander un jeton à un serveur producteur de jetons, l'utilisateur va cacher l'identifiant du serveur cible de la manière suivante.
Il combine au moyen d’un fonction de compression non inversible, parfois appelée "fonction de hachage", l'identifiant du serveur cible avec une valeur aléatoire, appelée "valeur de salage" (sait value). Le résultat du calcul est placé dans le champ (f) intitulé "suite d'octets représentative du serveur cible ". L'identifiant d'un serveur cible comportant une sémantique n'est donc jamais présent dans le jeton de sécurité et l'identifiant ou l'identité du serveur cible reste ainsi totalement inconnu du serveur producteur du jeton. En particulier, l'identifiant ou l'identité d’un serveur d'attributs (21) reste totalement inconnu d'un serveur d’identité (22). Ceci constitue une caractéristique avantageuse du procédé.
Il est cependant nécessaire que le serveur cible puisse savoir que le jeton de sécurité lui est bien destiné. Pour cela, l'application cliente communique au serveur cible la valeur de salage tandis qu'une règle fixe est définie pour transformer l'adresse du serveur cible en identifiant de serveur cible. Ainsi, le serveur cible connaissant à la fois la valeur de salage et son propre identifiant est en mesure de vérifier que la valeur contenue dans le champ (f) est bien celle qu'il aura recalculée localement. Si cela n'était pas le cas, le jeton devra être refusé. Pour la création d’un compte sur un serveur producteur de jetons, l'utilisateur transmet au microcircuit: - un identifiant du serveur producteur de jetons.
En retour, le microcircuit produit un message formaté qui comporte : (a) le pseudonyme généré par le microcircuit pour ce serveur, (b) la valeur de la clé publique générée par le microcircuit pour ce serveur, (c) une signature numérique sur les trois données précédentes, calculée au moyen de la clé privée générée par le microcircuit pour ce serveur, (d) une information publique, telle un certificat de clé publique, par exemple du type X.509, permettant de vérifier les données signées avec la clé privée propre à ce microcircuit, et (e) une signature numérique sur l'ensemble des données précédentes au moyen de la clé privée propre au microcircuit.
Nota 1 : le champ (d) pourrait aussi faire partie des données signées par la clé privée générée par le microcircuit pour ce serveur, mais pour des raisons strictement de sécurité cela n'est pas indispensable.
Nota 2: une signature numérique est calculée généralement à l'aide d'une clé privée sur une valeur de hachage calculée à l’aide d'un algorithme de compression non inversible (one way hash function, en anglais) complétée le cas échéant par des bits de remplissage (padding bits, en anglais).
Le champ (c) permet de prouver la possession de la clé publique contenue dans le champ (b).
Le champ (e) permet au serveur producteur de jetons de s'assurer à l'aide du champ (d) que les données reçues proviennent bien d'un microcircuit conforme aux exigences du procédé et que c’est bien ce certificat qui appartient au microcircuit. Une fois ces vérifications effectuées, le serveur producteur de jetons crée un compte associé au pseudonyme et à la clé publique qui ont été générés par le microcircuit.
Nota 3: Les champs (d) et (e) peuvent être en outre considérés comme étant une protection contre des ouvertures de comptes intempestives, car seul un détenteur de microcircuit conforme aux exigences du procédé sera en mesure d'ouvrir un compte sur un serveur producteur de jetons.
Si la réponse du serveur producteur de jetons à la demande de création du compte est positive, alors l'utilisateur doit confirmer qu'il est d'accord pour créer une nouvelle entrée dans son microcircuit en présentant un elD-PIN. Dans le cas contraire, les données qui étaient temporairement stockées dans la mémoire du microcircuit seraient effacées.
Pour la création d'un compte sur un fournisseur de service (11), l'utilisateur transmet au microcircuit: - l'identifiant du fournisseur de service (11).
En retour, le microcircuit produit un message formaté qui comporte : (a) le pseudonyme généré par le microcircuit pour ce serveur, (b) la valeur de la clé publique générée par le microcircuit pour ce serveur, (c) une signature numérique sur les trois données précédentes générée au moyen de la clé privée associée à ce serveur.
On observera que les paramètres (d) et (e) qui étaient présents auparavant pour la création d'un compte sur un serveur producteur de jetons, ne figurent pas dans la liste ci-dessus. Cela est à bon escient. En effet, s'ils étaient présents, cela permettrait aux serveurs fournisseurs de service (11) d'établir des liens entre leurs comptes respectifs.
Si la réponse d'un fournisseur de service (11) à la demande de création du compte est positive, alors l'utilisateur devra confirmer qu'il est d'accord pour créer une nouvelle entrée dans son microcircuit, par exemple en présentant un elD-PIN.
Un elD-PIN (electronic Identification - Personal Identification Number) est un PIN (Personal Identification Number) spécifique aux fonctions d’identité électronique doit être mis en œuvre. Il est connu du possesseur légitime du microcircuit et doit être présenté au microcircuit pour permettre l'exécution de certaines fonctions ou commandes du microcircuit liées à l'authentification. En effet, il peut exister un autre PIN sur un même microcircuit pour permettre l'exécution de certaines fonctions ou commandes circuit liées à la signature électronique. Si l'elD-PIN a déjà été présenté, et qu'il n'est pas souhaitable pour des raisons ergonomiques de demander à l'utilisateur de fournir "n fois" son elD-PIN dans un court laps de temps, l'application cliente pourra demander la confirmation au moyen d'une interaction homme-machine et présenter l'elD-PIN au microcircuit de manière transparente pour l'utilisateur. L'homme de l'art aura très certainement remarqué l'absence de l'utilisation de mécanisme permettant de détecter le rejeu ("replay" en anglais) de la demande de création de compte. En la circonstance, pour une demande de création de compte, l'usage d'un tel mécanisme n'est pas nécessaire, car un pseudonyme (qu'il ait été ou non généré par un microcircuit) sera refusé si un compte a déjà été ouvert avec succès sous ce pseudonyme sur le serveur.
Cependant et habituellement, dans tout échange de données du type requête/réponse entre un client et un serveur, il est nécessaire de mettre en place un mécanisme permettant de détecter le rejeu ("replay" en anglais) d'une requête ou d'une réponse. Deux techniques existent pour effectuer une telle protection : l'usage de défis ("challenges" en anglais) ou l'usage de nombres uniques ("unique numbers" en anglais). L'usage des défis nécessite un minimum de quatre échanges, tandis que l'usage des nombres uniques ne nécessite que deux échanges, avec en contrepartie l'usage d'horloges faiblement synchronisées vis à vis du Temps Coordonné Universel (UTC): à titre d'exemple, de l'ordre d'une dizaine de minutes. Cela est facile à obtenir avec la technologie actuelle. Des détails sont disponibles dans le standard ISO/IEC 10181-2:1996. Information technology -- Open Systems
Interconnection - Security frameworks for open Systems: Authentication framework.
Cependant, pour des opérations qui concernent des comptes déjà ouverts un tel mécanisme de détection de rejeu est nécessaire. Les opérations qui sont décrites ci-après permettent d'utiliser aussi bien de la technique des défis que de la technique des nombres uniques. Dans le premier cas, le défi reçu lors du second échange est incorporé dans les données véhiculées lors du troisième échange, tandis que dans le second cas, le nombre unique est directement incorporé dans les données véhiculées lors du premier échange. Le défi ou le nombre unique doit ainsi toujours être transmis par l'application cliente au microcircuit.
Pour l'authentification auprès d'un serveur à l'aide d'un pseudonyme, l'utilisateur transmet au microcircuit les éléments suivants: (a) un défi ou un nombre unique, selon la technique de rejeu choisie, (b) l'identifiant du serveur distant.
En retour, le microcircuit produit un message formaté qui comporte : (a) le défi ou le nombre unique, (b) le pseudonyme de l'utilisateur pour cette entrée, (c) une signature numérique appliquée sur les deux données ci-dessus en utilisant la clé privée associée à cette entrée.
Remarque: dans le cas de l'authentification auprès d'un producteur de jetons, la durée de vie du certificat du microcircuit peut conduire à ajouter deux éléments protocolaires complémentaires, dans la mesure où : (i) le certificat du microcircuit est renouvelable, et (ii) un tel renouvellement n'entraînerait pas une durée de validité du certificat supérieure à la durée de vie du microcircuit lui-même.
Les deux éléments protocolaires complémentaires sont alors les suivants: (d) le nouveau certificat, par exemple du type X.509, comportant la clé publique propre au microcircuit, et (e) une signature numérique sur l'ensemble des données précédentes au moyen de la clé privée propre au microcircuit. L'utilisateur aura ensuite deux possibilités: - envoyer directement ses messages au travers du protocole HTTPS (ou à défaut HTTP), ou bien - permettre l'authentification de ses messages en les faisant signer par le microcircuit au moyen de la clé privée associée à ce serveur et ce, que le protocole utilisé soit le protocole HTTP ou bien le protocole HTTPS.
Le choix sera à effectuer par l'utilisateur en fonction du volume des données à échanger et/ou de l'importance de la sémantique de ces données.
Pour l'authentification de messages auprès d'un serveur à l'aide d'un pseudonyme, l'utilisateur transmet au microcircuit les éléments suivants: (a) un défi ou un nombre unique, selon la technique de rejeu choisie, (b) l'identifiant du serveur distant, (c) le contenu du message qui doit faire l'objet de l'authentification.
En retour, le microcircuit produit un message formaté qui comporte : (a) le défi ou le nombre unique, (b) le pseudonyme de l'utilisateur pour cette entrée, (c) le contenu du message qui fait l'objet de l'authentification (data origin authentication), (d) une signature numérique appliquée sur les trois données précédentes en utilisant la clé privée associée à cette entrée.
NotaJ;: Alors que le protocole HTTPS assure à la fois l'intégrité et la confidentialité des données véhiculées entre un client et un serveur, le message transmis permet d'authentifier l'origine du message et du fait que ce message a bien transité par le microcircuit de l'utilisateur titulaire du pseudonyme.
Pour permettre la génération du message formaté par le microcircuit, l'utilisateur devra indiquer au microcircuit qu'il est d'accord pour s'authentifier, par exemple, en présentant un elD-PIN.
Il est maintenant utile de décrire la manière de faire générer une demande de jeton par un microcircuit afin que la demande de génération produite par le microcircuit puisse ensuite être transmise par l'application cliente à un serveur producteur de jetons.
Pour la génération d'une demande jeton adressée au microcircuit sécurisé, I utilisateur transmet au microcircuit sécurisé les éléments suivants: (a) un défi ou un nombre unique, (b) les types d'attributs et/ou les types et valeurs d'attributs que l'application cliente souhaite voir incorporés dans le jeton de sécurité, (c) une période de validité des attributs (pour un jeton multi sessions) ou un champ vide ou absent (pour un jeton mono session), (d) une suite d'octets représentative du serveur cible, (e) un pointeur relatif à une entrée située dans le microcircuit désignant le serveur cible, (f) un pointeur relatif à une entrée située dans le microcircuit désignant le serveur producteur de jetons.
Le champ (a) assure une protection contre le rejeu. Il est à noter que cette protection vient en complément de celle offerte par le protocole HTTPS, si celui-ci est mis en œuvre.
Le champ (b) permet à l'application cliente A, suite à un dialogue avec l'utilisateur, de ne demander que les attributs que l'utilisateur souhaite voir incorporés dans le jeton. Il s'agit de la combinatoire de deux principes liés au respect de la vie privée ("privacy" en anglais) connus sous les noms de "minimisation des données" ("data minimization" en anglais) et "consentement de l'utilisateur" ("user consent" en anglais).
Le champ (c) permet de délivrer des jetons de sécurité mono session ou multi sessions.
Le champ (d) est "copié et collé" dans le jeton de sécurité par le serveur producteur de jetons.
Le champ (e) est primordial car il permet de sélectionner le pseudonyme de l'utilisateur qui sera incorporé dans le jeton de sécurité. Il est particulièrement important de remarquer que ce pseudonyme doit déjà être présent dans le microcircuit sécurisé et qu'il a donc nécessairement été généré par le microcircuit sécurisé et qu'en conséquence cela ne pourra être aucun cas le pseudonyme utilisé par une autre personne avec qui le demandeur du jeton serait de connivence. C'est cette caractéristique fondamentale qui permet d'empêcher la transmission d'un attribut appartenant à une personne (ou à une entité) au profit d'une ou plusieurs autres personnes (ou entités), même si ces personnes (ou entités) sont de connivence.
Le champ (f) a deux usages: (i) il permet d'indiquer le pseudonyme de l'utilisateur tel qu'il est déjà connu du serveur producteur de jetons et qui sera contenu dans la demande du jeton de sécurité qui va être générée par le microcircuit, et (ii) il permet de sélectionner la clé privée associée au serveur producteur de jetons et qui sera utilisée par le microcircuit pour signer la demande de jeton.
En retour, le microcircuit sécurisé produit un message formaté qui comporte : (a) le défi ou le nombre unique, (b) les attributs demandés par l'utilisateur, (c) une période de validité des attributs (pour un jeton multi sessions) ou un champ vide ou absent (pour un jeton mono session), (d) la suite d'octets représentative du serveur cible, (e) le pseudonyme utilisé par l'utilisateur sur le serveur cible, (f) le pseudonyme utilisé par l'utilisateur sur le serveur producteur de jeton à qui le jeton de sécurité va être demandé, (g) une signature numérique appliquée sur l'ensemble des données précédentes, au moyen de la clé privée relative au serveur producteur de jetons.
En vérifiant le champ (a), le serveur producteur de jetons peut s'assurer que la commande reçue n'est pas le rejeu d'une commande envoyée auparavant.
En utilisant le champ (b), le serveur pourra incorporer les attributs demandés, bien évidemment dans la mesure où l'utilisateur les possède effectivement. L'utilisateur a la possibilité de demander chaque attribut soit en indiquant seulement son type, soit en indiquant à la fois son type et une valeur.
En utilisant le champ (c), le serveur pourra générer un jeton multi sessions ou un jeton mono session, dans la mesure où il supporte les deux types de jetons.
La valeur contenue dans le champ (d) est recopiée à l'aveugle à partir du champ (d) de la commande. Ce même champ sera par la suite recopiée à l'aveugle dans le champ (f) du jeton de sécurité par le serveur producteur de jetons. De la sorte, un serveur producteur de jetons ne peut pas identifier les serveurs consommateurs du jeton, par le simple examen des commandes reçues.
La valeur contenue dans le champ (e) est le pseudonyme qui provient de la valeur contenue dans le microcircuit sécurisé dans l'entrée pointée dans le champ (e) de la commande.
Le champ (f) permettra au serveur producteur de jetons de sélectionner la clé publique appropriée afin de lui permettre de vérifier la signature numérique contenue dans le champ (g).
Avant l'émission d'un jeton de sécurité, le serveur producteur de jetons doit vérifier que le certificat du microcircuit sécurisé attaché au compte n'est pas révoqué. Si ce certificat a été révoqué, alors le jeton demandé ne doit pas être émis.
Il est essentiel que le champ (e) ci-dessus provienne effectivement du microcircuit sécurisé et non d'une donnée extérieure, sans quoi il serait possible de modifier à sa guise le bénéficiaire du jeton. Hors, il existe une fonction permettant d'assurer l'intégrité et l'authentification de données externes (non encore décrite à ce stade de l'exposé). Il faut donc s'assurer que cette dernière fonction ne pourra jamais être utilisée pour mimer une demande de jeton signée.
Il existe plusieurs manières d'assurer l'impossibilité de faire une telle mascarade. Par exemple, en imposant l'ordre dans lequel les différents paramètres doivent être inclus dans la réponse ainsi qu'une codage pour chaque paramètre, par exemple du type TLV (Type, Longueur, Valeur) ou en utilisant des balises du type XML. L'avantage d'un codage TLV, tel que le BER (Basic Encoding Rules) ou le DER (Distinguished Encoding Rules) de l'ASN.1, est sa compacité.
Une autre façon de faire, est d'insérer systématiquement en tête du message (ou en queue du message) un code différent permettant de faire la différence entre une réponse à une commande de demande de jeton de sécurité et toute réponse à une autre commande, en particulier, une commande permettant d'assurer l'intégrité et l'authentification de données externes. A partir du moment où le codage des champs ou bien les données supplémentaires font partie des données qui entrent dans le calcul de la signature numérique, alors il est possible de discriminer entre les différents types de messages.
Si un utilisateur souhaite présenter à un serveur cible un jeton de sécurité qu'il a obtenu auprès d'un serveur producteur de jetons, deux variantes sont possibles, en particulier: (a) le jeton de sécurité peut être transmis après l'authentification de l'utilisateur au moyen de son pseudonyme; la liaison entre le message et le jeton étant alors réalisée grâce à l'usage du protocole HTTPS, (b) le jeton de sécurité peut faire partie du contenu d'un message faisant l'objet d'une authentification ("data origin authentication", en anglais); la liaison entre le message et le jeton étant alors réalisée qu'il y ait ou non la mise en oeuvre du protocole HTTPS.
Bien sûr, l'invention n'est pas limitée aux modes de réalisation préférés qui viennent d'être décrits, mais au contraire l'invention est définie par les revendications qui suivent.
Il apparaîtra en effet à l'homme de l'art que diverses modifications peuvent être apportées aux modes de réalisation du procédé décrit ci-dessus, à la lumière de l'enseignement qui vient de lui être divulgué.
Description des modes de réalisation
Le microcircuit sécurisé sera réalisé au moyen d'un unique composant électronique ou bien au moyen de plusieurs composants électroniques encapsulés dans un autre composant ou encore au moyen de plusieurs composants électroniques protégés par une enceinte sécurisée, généralement appelée "enceinte cryptographique", l'une ou l'autre de ces réalisations disposant des protections telles que décrites dans l'invention, tandis que ledit "microcircuit sécurisé" s'interfacera avec son environnement extérieur, soit au moyen d'une interface avec contacts, soit au moyen d'une interface sans contact.
Brève description des dessins
La Figure 1 illustre schématiquement l'architecture FIDO d'origine.
La Figure 2 illustre schématiquement l'architecture FIDO complétée selon l'invention.
La Figure 3 illustre les données essentielles contenues dans un microcircuit sécurisé selon l'invention.
Liste des abréviations utilisées ASN.1 : Abstract Syntax Notation One. BER : Basic Encoding Rules. CEN : Comité Européen de Normalisation. CHAT : Certificate Hôlder Authorization Template, ("Gabarit d'autorisation pour un porteur de certificat" en français). CRL : Certificate Révocation List ("Liste de Révocation de Certificats" (LRC) en français). CV certificate : Card Vérifiable certificate ("Certificat vérifiable par une carte" en français). DER : Distinguished Encoding Rules. EAL4 : Evaluation Assurance Level 4 ("Evaluation d'assurance de niveau 4" en français). elD-PIN: electronic Identification - Personal Identification Number ("nombre d'identification personnel pour l'identification électronique" en français). ETSI : European Télécommunications Standardisation Institute ("Institut Européen de Normalisation des Télécommunications" en français). FIDO : Fast Identity On line. ICC: Integrated Circuit Card ("carte à microcircuit " en français). HTTP : HyperText Transfer Protocol, ("Protocole de Transfert Hypertexte" en français). HTTPS : HyperText Transfer Protocol Secure, ("Protocole de Transfert Hypertexte Sécurisé" en français). OCSP: "One-line Certificate Status Protocol". PC : Politique de Certification ("Certification Policy" en anglais). PIN : Personal Identification Number ("Nombre d'identification Personnel" en français). PP : Profil de Protection ("Protection Profile" en anglais). TLV : Type, Longueur, Valeur ("Type, Length, Value" en anglais). TPM : Trusted Platform Module. UAF : Universal Authentication Framework ("Cadre d'Authentification Universel" en français). UTC : Universal Coordinated Time ("Temps Coordonné Universel" en français). XML : Extensible Markup Language. X.509 : Recommandation de l'ITU-T X.509 : Open Systems Interconnection -The Directory : Public-key and attribute certificate frameworks.
Liste des documents cités
- Application Interface for secure éléments used as Qualified electronic Signature (Seal-) Création Devices". Documents de travail du CEN TC 224 WG 17: " Draft EN 419 212-1 à draft EN 419 212-5", uniquement disponibles aux membres du CEN TC 224 WG 17 au moment du dépôt du document. - ASN.1 : Abstract Syntax Notation One. Recommandations ITU-T X.680 à X.683 (les documents ISO/IEC ont pour références 8824-1 à 8824-4). Les encodages BER, CER et DER sont spécifiés par la recommandation X.690. - ISO/IEC 10181 -2:1996. Information technology - Open Systems Interconnection - Security frameworks for open Systems: Authentication framework. - "elD and the principle of privacy by design". Présentation effectuée le 24 juin 2015, accessible à l'adresse suivante : http://docbox.etsi.org/Workshop/2015/201506_SECURITYWEEK/ elDAS_THREAD/S03_elD/DPSECURITYCONSULTING_PINKAS.pdf - Spécifications techniques de l'Alliance FIDO (Fast Identity On line), accessibles à l'adresse suivante: https://fidoalliance.org/specifications/download - Universal Authentication Framework - UAF. FIDO Alliance, accessible à l'adresse suivante: https://fidoalliance.org/specifications/download - Recommandation de l'ITU-T X.509. Information technology -Open Systems Interconnection - The Directory:
Public-key and attribute certificate frameworks.

Claims (15)

  1. Revendications Revendication 1. Procédé permettant, à partir d’une application cliente, d'accéder à un serveur cible en ligne au moyen d'un microcircuit sécurisé, d'un pseudonyme et d'un jeton de sécurité contenant des attributs, ledit jeton ayant été obtenu auprès d'un serveur producteur de jetons, qui peut être soit un fournisseur d’attributs, soit un fournisseur d’identité, caractérisé par le fait que l'application cliente est dans l'impossibilité de pouvoir octroyer le bénéfice dudit jeton à une autre application cliente, et que le procédé comprend les étapes suivantes: - la création d'un compte sur un serveur cible ou sur un serveur producteur de jeton au moyen d'un pseudonyme et d'une demande générés par un microcircuit sécurisé qui fournit, à la demande de l'application cliente, l'ensemble des données permettant la création du compte, - la création d'un compte sur un serveur producteur de jetons au moyen d’un pseudonyme et d'une demande générés par microcircuit sécurisé qui fournit, à la demande de l'application cliente, l'ensemble des données permettant la création du compte au moyen d'un pseudonyme et qui permet de démontrer qu'un microcircuit sécurisé fabriqué par un fournisseur de microcircuits selon un cahier des charges précis est effectivement mis en œuvre pour réaliser cette opération, - la demande d'un jeton de sécurité auprès d'un serveur producteur de jetons étant précisé que les données essentielles pour effectuer cette demande doivent être générées par le microcircuit sécurisé, - la génération d'un jeton de sécurité suite à une demande de jeton signée en provenance d'un microcircuit sécurisé, comportant deux champs caractéristiques, si, et seulement si, au plus tard au moment de la demande de jeton, le serveur producteur de jetons a obtenu l'assurance que la demande de jeton provenait bien d'un microcircuit sécurisé fabriqué par un fournisseur de microcircuits selon des caractéristiques précises, - l'acceptation du jeton de sécurité par le serveur cible, si le serveur cible se reconnaît en tant que serveur cible du jeton, si le jeton est reconnu comme étant valide, si un compte a été préalablement ouvert sur le serveur cible sous le pseudonyme contenu dans le jeton de sécurité et si le jeton de sécurité a été signé par un serveur producteur de jetons connu du serveur cible pour avoir obtenu l'assurance que la demande de jeton provenait bien d'un microcircuit fabriqué par un fournisseur de microcircuits selon des caractéristiques précises. Revendication
  2. 2. Procédé selon la revendication 1 caractérisé par le fait que chaque microcircuit sécurisé est livré par son fournisseur avec : - d'une part, une Information Publique contenue dans le microcircuit sécurisé permettant de savoir ou de déduire que l'octroi de ladite information publique a été conditionné par le respect des exigences de sécurité et de fonctionnalités applicables au microcircuit sécurisé et décrites dans le cadre de ladite invention, et - d'autre part, une clé privée associée qui sera utilisée impérativement pour effectuer certaines opérations précises, de manière telle que les signatures numériques effectués en utilisant ladite clé privée soient vérifiables à partir de ladite information publique, et où l'Information Publique contient au moins une information permettant de savoir, par le biais d'un contact à un serveur, si une donnée publique spécifique au microcircuit sécurisé est toujours valide (fonctionnement en liste blanche) ou bien a été invalidée (fonctionnement en liste noire). Revendication
  3. 3. Selon une réalisation préférée de la revendication 2 chaque microcircuit sécurisé est livré par son fournisseur avec : - un certificat de clé publique, et - une clé privée associée, où la clé privée et la clé publique constituent une paire de clés asymétriques unique, et où le certificat de clé publique contient au moins une information permettant de savoir, par le biais d'un contact à un serveur, si une donnée publique spécifique au microcircuit sécurisé est toujours valide (fonctionnement en liste blanche) ou bien a été invalidée (fonctionnement en liste noire). Revendication
  4. 4. Selon une autre réalisation préférée de la revendication 2, chaque microcircuit sécurisé est livré par son fournisseur avec : - une Information Publique contenant, en particulier, une donnée publique propre au microcircuit sécurisé, un identifiant du fournisseur de microcircuits, ainsi qu'une clé publique commune à un ensemble de microcircuits produits par ledit fournisseur de microcircuits, et - une clé privée propre au microcircuit, calculée par le ledit fournisseur de microcircuits à partir d'une clé privée unique gardée secrète par le ledit fournisseur de microcircuits, et où l'Information Publique contient au moins une information permettant de savoir, par le biais d'un contact à un serveur, si une donnée publique spécifique au microcircuit sécurisé est toujours valide ou bien a été invalidée. Revendication
  5. 5. Procédé selon les revendications 1 et 2 caractérisé en ce que le microcircuit sécurisé, selon la procédure n° 1 décrite ci-dessous, génère à la demande de l'application cliente les données permettant de mettre en œuvre la création d'un compte sur un fournisseur de service donné ou sur un serveur producteur de jetons donné au moyen d'un pseudonyme, la demande de l'application cliente étant accompagnée au minimum du paramètre suivant: - un identifiant du serveur objet de la demande, tandis qu'en retour, et si l'identifiant procuré par l'application cliente n'est pas déjà présent dans le microcircuit sécurisé, ledit microcircuit : - génère un pseudonyme, qui est une valeur aléatoire de taille suffisante vis à vis du nombre d'utilisateurs potentiellement authentifiables sur le serveur pour que la probabilité qu'il puisse exister une collision entre pseudonymes soit quasiment nulle, et - génère une bi-clé (i.e. une paire de clés, c'est à dire une clé privée et une clé publique), puis, après l'accord de l'utilisateur légitime du microcircuit sécurisé, fournit des donnés permettant l'authentification vis à vis du serveur cible en signant numériquement à l'aide de la clé privée générée ci-dessus au minimum les données suivantes: (a) le pseudonyme généré par le microcircuit sécurisé pour ce serveur, (b) la valeur de la clé publique générée le microcircuit sécurisé pour ce serveur, et mémorise dans une entrée les informations suivantes: - l'identifiant du serveur, - le pseudonyme généré de manière aléatoire pour ce serveur, - la clé privée correspondant à la bi-clé générée précédemment par le microcircuit sécurisé pour ce serveur, et est aussi en mesure de mémoriser, associée à chaque entrée, de manière non restrictive, ni exhaustive : - une date de création de ladite entrée (si celle-ci est fournie par l'application cliente), - une date de dernière utilisation de ladite entrée (si celle-ci est fournie par l'application cliente). Revendication
  6. 6. Procédé selon les revendications 1 et 2 caractérisé en ce que le microcircuit sécurisé, selon la procédure n° 2 décrite ci-dessous, fournit à la demande de l'application cliente les données permettant de mettre en œuvre la création d'un compte sur un serveur producteur de jetons donné au moyen d'un pseudonyme, tout en apportant simultanément au serveur la preuve qu'un microcircuit sécurisé conforme aux exigences décrites dans le cadre de ladite invention est utilisé, la demande de l'application cliente étant accompagnée au minimum du paramètre suivant: - un identifiant du serveur producteur de jetons objet de la demande, tandis qu'en retour, et si l'identifiant procuré par l'application cliente n'est pas déjà présent dans le microcircuit sécurisé, ledit microcircuit : - génère un pseudonyme, qui est une valeur aléatoire de taille suffisante vis à vis du nombre d'utilisateurs potentiellement authentifiables sur le serveur pour que la probabilité qu'il puisse exister une collision entre pseudonymes soit quasiment nulle, et - génère une bi-clé (i.e. une paire de clés: l'une privée et l'autre publique), puis, après l'accord de l'utilisateur légitime du microcircuit sécurisé, fournit des donnés permettant l'authentification vis à vis du serveur cible en fournissant et en signant numériquement à l'aide de la clé privée générée ci-dessus au minimum les données suivantes: (a) le pseudonyme généré par le microcircuit sécurisé pour ce serveur producteur de jetons, (b) la valeur de la clé publique générée le microcircuit sécurisé pour ce serveur producteur de jetons, et en plaçant cette signature numérique dans un champ (c), et de surcroît en signant numériquement à l'aide de la clé privé propre au microcircuit sécurisé : - la signature numérique précédente présente dans le champ (c) ou bien les données (a) et (b), ainsi que - l'information publique propre au microcircuit sécurisé, qui est placée dans un champ (d), et place cette seconde signature numérique dans un champ (e), et mémorise dans une entrée les informations suivantes: - l'identifiant du serveur producteur de jetons, - le pseudonyme généré de manière aléatoire pour ce serveur producteur de jetons, - la clé privée correspondant à la bi-clé générée précédemment par le microcircuit sécurisé pour ce serveur producteur de jetons, et, optionnellement, un indicateur précisant que l'entrée a été créée selon cette procédure n° 2 dans la mesure où l'application appelante ne désire pas mémoriser cet indicateur, et est aussi en mesure de mémoriser, associée à chaque entrée, de manière non restrictive, ni exhaustive : - une date de création de ladite entrée (si celle-ci est fournie par l'application cliente), - une date de dernière utilisation de ladite entrée (si celle-ci est fournie par l'application cliente), étant entendu que ladite procédure n° 2 ne doit en aucun cas être utilisée par l'application cliente vis à vis d'un fournisseur de service. Revendication
  7. 7. Procédé selon les revendications 1,2, 5 et 6 caractérisé par le fait qu'une demande de jeton de sécurité adressée au microcircuit sécurisé par l'application appelante à l'intention d'un serveur producteur de jetons effectuée selon la procédure n° 3 décrite ci-dessous, ne peut être générée par le microcircuit sécurisé qu'à partir du moment où il existe au moins déjà deux entrées dans le microcircuit sécurisé, la première désignant un serveur cible, c'est à dire le serveur pour lequel le jeton est destiné, la seconde désignant un serveur producteur de jetons dont l'entrée a été créée selon la procédure n° 2, et dans ce cas, l'application cliente doit fournir au microcircuit sécurisé les éléments suivants: (a) un défi ou un nombre unique, afin de pouvoir détecter des cas de rejeu, (b) les types d'attributs et/ou les valeurs d'attributs que l'application cliente souhaite voir incorporés dans le jeton de sécurité, (c) une période de validité des attributs (pour un jeton multi sessions) ou un champ vide ou absent (pour un jeton mono session), (d) une suite d'octets représentative du serveur cible, (e) un pointeur relatif à une entrée située dans le microcircuit sécurisé désignant le désignant le serveur cible, (f) un pointeur relatif à une entrée située dans le microcircuit sécurisé désignant le serveur producteur de jetons, tandis qu'en retour, le microcircuit sécurisé, après l'accord de l'utilisateur légitime du microcircuit sécurisé, produit un message formaté qui comporte : (a) le défi ou le nombre unique, (b) les attributs demandés par l'utilisateur, (c) une période de validité des attributs (pour un jeton multi sessions) ou un champ vide ou absent (pour un jeton mono session), (d) la suite d'octets représentative du serveur cible, (e) le pseudonyme contenu dans l'entrée pointée par le paramètre (e) de la commande, (f) le pseudonyme contenu dans l'entrée pointée par le paramètre (f) de la commande, (g) une signature numérique appliquée sur l'ensemble des données précédentes, au moyen de la clé privée relative au serveur producteur de jeton. Revendication
  8. 8. Procédé selon les revendications 1,2, 5 et 6 caractérisé par le fait qu'une demande de jeton de sécurité adressée au microcircuit sécurisé par l'application appelante à l'intention d'un serveur producteur de jetons, effectuée selon la procédure n° 4 décrite ci-dessous, ne peut être générée par le microcircuit sécurisé qu'à partir du moment où il existe au moins déjà deux entrées dans le microcircuit sécurisé, la première désignant un serveur cible, c'est à dire le serveur pour lequel le jeton est destiné, la seconde désignant un serveur producteur de jetons dont l'entrée n'a pas été créée selon la procédure n° 2, et dans ce cas, l'application cliente doit fournir au microcircuit sécurisé les éléments suivants: (a) un défi ou un nombre unique, afin de pouvoir détecter des cas de rejeu, (b) les types d'attributs et/ou les valeurs d'attributs que l'application cliente souhaite voir incorporés dans le jeton de sécurité, (c) une période de validité des attributs (pour un jeton multi sessions) ou un champ vide ou absent (pour un jeton mono session), (d) une suite d'octets représentative du serveur cible, (e) un pointeur relatif à une entrée située dans le microcircuit sécurisé désignant le serveur cible, (f) un pointeur relatif à une entrée située dans le microcircuit sécurisé désignant le serveur producteur de jetons, tandis qu'en retour, le microcircuit sécurisé, après l'accord de l'utilisateur légitime du microcircuit sécurisé, produit un message formaté qui comporte : (a) le défi ou le nombre unique, (b) les attributs demandés par l'utilisateur, (c) une période de validité des attributs (pour un jeton multi sessions) ou un champ vide ou absent (pour un jeton mono session), (d) la suite d'octets représentative du serveur cible, (e) le pseudonyme contenu dans l'entrée pointée par le paramètre (e) de la commande, (f) le pseudonyme contenu dans l'entrée pointée par le paramètre (f) de la commande, (g) une signature numérique appliquée sur l'ensemble des données précédentes, au moyen de la clé privée relative au serveur producteur de jetons, (h) l'information publique propre au microcircuit sécurisé, (i) une signature numérique appliquée sur l'ensemble des données précédentes, au moyen de la clé privée propre au microcircuit sécurisé. Revendication
  9. 9. Procédé selon les revendications 5, 6, 7 et 8 caractérisé par le fait que le microcircuit sécurisé formate chaque champ de ses réponses signées de manière non ambigüe et que les données utilisées pour réaliser ce formatage font elles-mêmes parties des données signées de sorte qu'aucune opération ne peut, d'un point de vue fonctionnel, être confondue avec une autre opération et qu'en conséquence chacune d'entre elles peut être identifiée de manière non ambigüe et que les valeurs utilisées pour cette identification font partie des données signées, et que si des opérations supplémentaires aux opérations décrites dans ces revendications devaient être mises en œuvre par le microcircuit sécurisé, en aucun cas une réponse à l'une quelconque de ces opérations supplémentaires, à partir du moment où elle est signée, ne devra pouvoir être confondue avec une autre réponse signée et tout particulièrement avec les réponses signées du microcircuit sécurisé suite à des demandes de jeton telles qu'effectuées au moyen des procédures n° 3 et n° 4, respectivement décrites dans les revendications 7 et 8. Revendication
  10. 10. Procédé selon les revendications 1 et 7 ou 8 caractérisé par le fait qu'un jeton de sécurité émis par un serveur producteur de jetons suite à une demande signée en provenance d'un microcircuit sécurisé comporte, pour désigner le propriétaire du jeton, un champ contenant le pseudonyme d'un propriétaire déjà connu du serveur cible et que, du fait du processus menant à son incorporation dans le jeton, ce pseudonyme ne peut avoir été généré que par un microcircuit sécurisé au moyen d'un générateur pseudo aléatoire et qu'en conséquence sa valeur ne pourra avoir été librement choisie par quiconque. Revendication
  11. 11. Procédé selon les revendications 1 et 7 ou 8 caractérisé par le fait qu'un jeton de sécurité émis par un serveur producteur de jetons, suite à une demande signée en provenance d'un microcircuit sécurisé, comporte pour désigner le serveur cible auquel le jeton est destiné, une suite d'octets qui n'est pas interprétable par le serveur producteur de jetons, car cette suite d'octets est d'abord localement calculée par l'application cliente en utilisant une fonction de hachage et deux paramètres en entrée: une valeur de salage et un identifiant du serveur cible, puis communiquée au serveur producteur de jetons en tant que paramètre de la demande afin d'être incorporée dans le jeton et en conséquence lorsque l'application cliente communique au serveur cible concomitamment avec le jeton, cet identifiant et cette valeur de salage, ce dernier peut, grâce à ces deux valeurs, se reconnaître puis combiner ces deux valeurs à l'aide de la fonction de hachage pour retrouver la suite d'octets représentative présente dans le jeton de telle sorte que le serveur cible peut vérifier que le jeton de sécurité lui est effectivement destiné. Revendication
  12. 12. Procédé selon les revendications 5, 6, 7 et 8 caractérisé en ce que l'accord de l'utilisateur légitime du microcircuit sécurisé mentionné dans les revendications susvisées est obtenu: (a) soit par la présentation d'un code PIN (Personal Identification Number) ou d'un code d'activation par le propriétaire légitime du microcircuit sécurisé qui est nécessaire pour autoriser certaines opérations liées à l'authentification; ce code PIN étant appelé en la circonstance un "elD-PIN", (b) soit par la comparaison par le microcircuit sécurisé d'une donnée biométrique propre à l'utilisateur légitime du microcircuit sécurisé qui est nécessaire pour autoriser certaines opérations liées à l'authentification, (c) soit par une combinatoire d'un elD-PIN et d'une donnée biométrique propre à l'utilisateur légitime du microcircuit sécurisé. Revendication
  13. 13. Procédé selon les revendications 1,2, 5, 6, 7, 8 et 12 caractérisé par le fait que le microcircuit sécurisé utilisé dans le cadre du procédé doit avoir les propriétés habituelles d'un "module de sécurité" ("security module" en anglais) ou d'un élément sécurisé ("secure element" en anglais) au sens des règles de l'art, et en particulier, une résistance aux attaques physiques externes, une résistance aux attaques cryptographiques différentielles, l'impossibilité de pouvoir dupliquer le contenu du microcircuit sécurisé si celui-ci ne l'autorise pas, et de surcroît, doit contenir les données décrites dans la revendication 2, doit supporter la procédure n° 1, doit supporter la procédure n° 3 s'il supporte la procédure n° 2, doit supporter la procédure n° 4 s'il supporte pas la procédure n° 2 et doit être conforme aux exigences spécifiées dans la revendication 12. Revendication
  14. 14. Procédé selon les revendications 1 et 7 ou 8, et 13 caractérisé en ce qu'un serveur producteur de jetons n'accepte d'émettre un jeton de sécurité suite à une demande de jeton pour un utilisateur identifié sous un pseudonyme donné que s'il est en mesure de vérifier que: (1 ) il ne s'agit pas du rejeu d'une demande de jeton, soit en contrôlant que le défi correspond bien à celui qui a été envoyé, soit en contrôlant que le nombre unique se trouve dans la fourchette de temps autorisé et que ce nombre unique ne figure pas déjà parmi les nombres uniques mémorisés durant cette fourchette de temps, (2) le pseudonyme désignant le serveur producteur de jetons dans la demande de jeton lui est connu, (3) le compte attaché à ce pseudonyme n'est ni temporairement, ni définitivement invalidé, (4) la demande de jeton est effectivement signée par la clé privée associée au compte, (5) l'information publique correspondant à la clé privée du microcircuit sécurisé qui a été mise en œuvre lors de l'ouverture du compte ou bien au plus tard lors de la demande du jeton est toujours valide ou bien n'est ni expirée, ni révoquée, (6) l'information publique a bien été émise par une autorité de confiance qui ne délivre une telle information qu'après s'être assuré que le microcircuit sécurisé répond à un cahier des charges précis lui permettant de savoir que toutes les exigences de sécurité applicables au microcircuit sécurisé et qui sont décrites à la revendication 13 sont respectées. Revendication
  15. 15. Procédé selon les revendications 1,5, 10, 11 et 14 caractérisé par le fait qu'un serveur cible n'acceptera d'associer, après les vérifications d'usage, à un compte ouvert sous un pseudonyme les attributs contenus dans un jeton de sécurité, que : (1) si un compte a déjà été ouvert sur ce serveur sous le pseudonyme contenu dans le champ ad-hoc du jeton de sécurité, et (2) si ce compte n'est ni temporairement, ni définitivement invalidé, et (3) si la date à laquelle le jeton a été émis est voisine du temps présent ou bien si une période de validité est indiquée dans le jeton, si le temps présent est inclus dans cette période de validité, et (4) si le serveur cible se reconnaît en tant que destinataire du jeton, et (5) si le jeton de sécurité a été signé par un serveur producteur de jetons connu du serveur cible pour effectuer l'ensemble des vérifications prescrites à la revendication 14.
FR1501894A 2015-09-11 2015-09-11 Procede d'acces a un service en ligne au moyen d'un microcircuit securise et de jetons de securite restreignant l'utilisation de ces jetons a leur detenteur legitime Withdrawn FR3041195A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
FR1501894A FR3041195A1 (fr) 2015-09-11 2015-09-11 Procede d'acces a un service en ligne au moyen d'un microcircuit securise et de jetons de securite restreignant l'utilisation de ces jetons a leur detenteur legitime
PCT/EP2016/071386 WO2017042375A1 (fr) 2015-09-11 2016-09-10 Procédé d'accès à un service en ligne au moyen de jetons d'accès et d'un élément sécurisé limitant l'utilisation de ces jetons d'accès à leur propriétaire légitime
PCT/EP2016/076261 WO2017042400A1 (fr) 2015-09-11 2016-10-31 Procédé d'accès à un service en ligne au moyen de jetons d'accès et d'éléments sécurisés limitant l'utilisation de ces jetons d'accès à leur propriétaire légitime

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1501894A FR3041195A1 (fr) 2015-09-11 2015-09-11 Procede d'acces a un service en ligne au moyen d'un microcircuit securise et de jetons de securite restreignant l'utilisation de ces jetons a leur detenteur legitime

Publications (1)

Publication Number Publication Date
FR3041195A1 true FR3041195A1 (fr) 2017-03-17

Family

ID=55345859

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1501894A Withdrawn FR3041195A1 (fr) 2015-09-11 2015-09-11 Procede d'acces a un service en ligne au moyen d'un microcircuit securise et de jetons de securite restreignant l'utilisation de ces jetons a leur detenteur legitime

Country Status (2)

Country Link
FR (1) FR3041195A1 (fr)
WO (1) WO2017042375A1 (fr)

Families Citing this family (119)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11315114B2 (en) 2016-12-28 2022-04-26 Capital One Services, Llc Dynamic transaction card protected by multi-factor authentication
US10546444B2 (en) 2018-06-21 2020-01-28 Capital One Services, Llc Systems and methods for secure read-only authentication
US11216806B2 (en) 2018-09-19 2022-01-04 Capital One Services, Llc Systems and methods for providing card interactions
US10505738B1 (en) 2018-10-02 2019-12-10 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10582386B1 (en) 2018-10-02 2020-03-03 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
WO2020072694A1 (fr) 2018-10-02 2020-04-09 Capital One Services, Llc Systèmes et procédés d'authentification cryptographique de cartes sans contact
WO2020072440A1 (fr) 2018-10-02 2020-04-09 Capital One Services, Llc Systèmes et procédés d'authentification cryptographique de cartes sans contact
WO2020072537A1 (fr) 2018-10-02 2020-04-09 Capital One Services, Llc Systèmes et procédés pour authentification cryptographique de cartes sans contact
US10581611B1 (en) 2018-10-02 2020-03-03 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10592710B1 (en) 2018-10-02 2020-03-17 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
CA3110521A1 (fr) 2018-10-02 2020-04-09 Capital One Services, Llc Systemes et procedes pour authentification cryptographique de cartes sans contact
MX2021003138A (es) 2018-10-02 2021-05-14 Capital One Services Llc Sistemas y metodos para autentificacion criptografica de tarjetas sin contacto.
US10565587B1 (en) 2018-10-02 2020-02-18 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10489781B1 (en) 2018-10-02 2019-11-26 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10860814B2 (en) 2018-10-02 2020-12-08 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10841091B2 (en) 2018-10-02 2020-11-17 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10949520B2 (en) 2018-10-02 2021-03-16 Capital One Services, Llc Systems and methods for cross coupling risk analytics and one-time-passcodes
US10511443B1 (en) 2018-10-02 2019-12-17 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
WO2020072670A1 (fr) 2018-10-02 2020-04-09 Capital One Services, Llc Systèmes et procédés pour l'authentification cryptographique de cartes sans contact
US10909527B2 (en) 2018-10-02 2021-02-02 Capital One Services, Llc Systems and methods for performing a reissue of a contactless card
US11210664B2 (en) 2018-10-02 2021-12-28 Capital One Services, Llc Systems and methods for amplifying the strength of cryptographic algorithms
US10579998B1 (en) 2018-10-02 2020-03-03 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
SG11202101171VA (en) 2018-10-02 2021-03-30 Capital One Services Llc Systems and methods for cryptographic authentication of contactless cards
KR20210065961A (ko) 2018-10-02 2021-06-04 캐피탈 원 서비시즈, 엘엘씨 비접촉식 카드의 암호화 인증을 위한 시스템 및 방법
US10685350B2 (en) 2018-10-02 2020-06-16 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
CA3115252A1 (fr) 2018-10-02 2020-04-09 Capital One Services, Llc Systemes et procedes pour authentification cryptographique de cartes sans contact
US10542036B1 (en) 2018-10-02 2020-01-21 Capital One Services, Llc Systems and methods for signaling an attack on contactless cards
US10554411B1 (en) 2018-10-02 2020-02-04 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10607214B1 (en) 2018-10-02 2020-03-31 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10733645B2 (en) 2018-10-02 2020-08-04 Capital One Services, Llc Systems and methods for establishing identity for order pick up
US10771254B2 (en) 2018-10-02 2020-09-08 Capital One Services, Llc Systems and methods for email-based card activation
US10771253B2 (en) 2018-10-02 2020-09-08 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
BR112021004710A2 (pt) 2018-10-02 2021-06-08 Capital One Services, Llc sistema e método para transmitir dados
US10664830B1 (en) 2018-12-18 2020-05-26 Capital One Services, Llc Devices and methods for selective contactless communication
US20200226581A1 (en) 2019-01-11 2020-07-16 Capital One Services, Llc Systems and methods for touch screen interface interaction using a card overlay
US11037136B2 (en) 2019-01-24 2021-06-15 Capital One Services, Llc Tap to autofill card data
US10467622B1 (en) 2019-02-01 2019-11-05 Capital One Services, Llc Using on-demand applications to generate virtual numbers for a contactless card to securely autofill forms
US10510074B1 (en) 2019-02-01 2019-12-17 Capital One Services, Llc One-tap payment using a contactless card
US11120453B2 (en) 2019-02-01 2021-09-14 Capital One Services, Llc Tap card to securely generate card data to copy to clipboard
US10425129B1 (en) 2019-02-27 2019-09-24 Capital One Services, Llc Techniques to reduce power consumption in near field communication systems
US10523708B1 (en) 2019-03-18 2019-12-31 Capital One Services, Llc System and method for second factor authentication of customer support calls
US10535062B1 (en) 2019-03-20 2020-01-14 Capital One Services, Llc Using a contactless card to securely share personal data stored in a blockchain
US10438437B1 (en) 2019-03-20 2019-10-08 Capital One Services, Llc Tap to copy data to clipboard via NFC
US10643420B1 (en) 2019-03-20 2020-05-05 Capital One Services, Llc Contextual tapping engine
US10984416B2 (en) 2019-03-20 2021-04-20 Capital One Services, Llc NFC mobile currency transfer
US10970712B2 (en) 2019-03-21 2021-04-06 Capital One Services, Llc Delegated administration of permissions using a contactless card
US10467445B1 (en) 2019-03-28 2019-11-05 Capital One Services, Llc Devices and methods for contactless card alignment with a foldable mobile device
US11521262B2 (en) 2019-05-28 2022-12-06 Capital One Services, Llc NFC enhanced augmented reality information overlays
US10516447B1 (en) 2019-06-17 2019-12-24 Capital One Services, Llc Dynamic power levels in NFC card communications
US11392933B2 (en) 2019-07-03 2022-07-19 Capital One Services, Llc Systems and methods for providing online and hybridcard interactions
US10871958B1 (en) 2019-07-03 2020-12-22 Capital One Services, Llc Techniques to perform applet programming
US11694187B2 (en) 2019-07-03 2023-07-04 Capital One Services, Llc Constraining transactional capabilities for contactless cards
US12086852B2 (en) 2019-07-08 2024-09-10 Capital One Services, Llc Authenticating voice transactions with payment card
US10713649B1 (en) 2019-07-09 2020-07-14 Capital One Services, Llc System and method enabling mobile near-field communication to update display on a payment card
US10498401B1 (en) 2019-07-15 2019-12-03 Capital One Services, Llc System and method for guiding card positioning using phone sensors
US10885514B1 (en) 2019-07-15 2021-01-05 Capital One Services, Llc System and method for using image data to trigger contactless card transactions
US10733601B1 (en) 2019-07-17 2020-08-04 Capital One Services, Llc Body area network facilitated authentication or payment authorization
US11182771B2 (en) 2019-07-17 2021-11-23 Capital One Services, Llc System for value loading onto in-vehicle device
US10832271B1 (en) 2019-07-17 2020-11-10 Capital One Services, Llc Verified reviews using a contactless card
US11521213B2 (en) 2019-07-18 2022-12-06 Capital One Services, Llc Continuous authentication for digital services based on contactless card positioning
US10506426B1 (en) 2019-07-19 2019-12-10 Capital One Services, Llc Techniques for call authentication
US10541995B1 (en) 2019-07-23 2020-01-21 Capital One Services, Llc First factor contactless card authentication system and method
US10701560B1 (en) 2019-10-02 2020-06-30 Capital One Services, Llc Client device authentication using contactless legacy magnetic stripe data
US10733283B1 (en) 2019-12-23 2020-08-04 Capital One Services, Llc Secure password generation and management using NFC and contactless smart cards
US10862540B1 (en) 2019-12-23 2020-12-08 Capital One Services, Llc Method for mapping NFC field strength and location on mobile devices
US11651361B2 (en) 2019-12-23 2023-05-16 Capital One Services, Llc Secure authentication based on passport data stored in a contactless card
US10885410B1 (en) 2019-12-23 2021-01-05 Capital One Services, Llc Generating barcodes utilizing cryptographic techniques
US10657754B1 (en) 2019-12-23 2020-05-19 Capital One Services, Llc Contactless card and personal identification system
US11615395B2 (en) 2019-12-23 2023-03-28 Capital One Services, Llc Authentication for third party digital wallet provisioning
US11113685B2 (en) 2019-12-23 2021-09-07 Capital One Services, Llc Card issuing with restricted virtual numbers
US10853795B1 (en) 2019-12-24 2020-12-01 Capital One Services, Llc Secure authentication based on identity data stored in a contactless card
US11200563B2 (en) 2019-12-24 2021-12-14 Capital One Services, Llc Account registration using a contactless card
US10664941B1 (en) 2019-12-24 2020-05-26 Capital One Services, Llc Steganographic image encoding of biometric template information on a card
US10909544B1 (en) 2019-12-26 2021-02-02 Capital One Services, Llc Accessing and utilizing multiple loyalty point accounts
US10757574B1 (en) 2019-12-26 2020-08-25 Capital One Services, Llc Multi-factor authentication providing a credential via a contactless card for secure messaging
US11038688B1 (en) 2019-12-30 2021-06-15 Capital One Services, Llc Techniques to control applets for contactless cards
US11455620B2 (en) 2019-12-31 2022-09-27 Capital One Services, Llc Tapping a contactless card to a computing device to provision a virtual number
US10860914B1 (en) 2019-12-31 2020-12-08 Capital One Services, Llc Contactless card and method of assembly
US11210656B2 (en) 2020-04-13 2021-12-28 Capital One Services, Llc Determining specific terms for contactless card activation
US10915888B1 (en) 2020-04-30 2021-02-09 Capital One Services, Llc Contactless card with multiple rotating security keys
US11030339B1 (en) 2020-04-30 2021-06-08 Capital One Services, Llc Systems and methods for data access control of personal user data using a short-range transceiver
US11823175B2 (en) 2020-04-30 2023-11-21 Capital One Services, Llc Intelligent card unlock
US10861006B1 (en) 2020-04-30 2020-12-08 Capital One Services, Llc Systems and methods for data access control using a short-range transceiver
US11222342B2 (en) 2020-04-30 2022-01-11 Capital One Services, Llc Accurate images in graphical user interfaces to enable data transfer
US10963865B1 (en) 2020-05-12 2021-03-30 Capital One Services, Llc Augmented reality card activation experience
US11063979B1 (en) 2020-05-18 2021-07-13 Capital One Services, Llc Enabling communications between applications in a mobile operating system
US11100511B1 (en) 2020-05-18 2021-08-24 Capital One Services, Llc Application-based point of sale system in mobile operating systems
US11062098B1 (en) 2020-08-11 2021-07-13 Capital One Services, Llc Augmented reality information display and interaction via NFC based authentication
US12165149B2 (en) 2020-08-12 2024-12-10 Capital One Services, Llc Systems and methods for user verification via short-range transceiver
US11482312B2 (en) 2020-10-30 2022-10-25 Capital One Services, Llc Secure verification of medical status using a contactless card
US11165586B1 (en) 2020-10-30 2021-11-02 Capital One Services, Llc Call center web-based authentication using a contactless card
US11373169B2 (en) 2020-11-03 2022-06-28 Capital One Services, Llc Web-based activation of contactless cards
US11216799B1 (en) 2021-01-04 2022-01-04 Capital One Services, Llc Secure generation of one-time passcodes using a contactless card
US11682012B2 (en) 2021-01-27 2023-06-20 Capital One Services, Llc Contactless delivery systems and methods
US11687930B2 (en) 2021-01-28 2023-06-27 Capital One Services, Llc Systems and methods for authentication of access tokens
US11562358B2 (en) 2021-01-28 2023-01-24 Capital One Services, Llc Systems and methods for near field contactless card communication and cryptographic authentication
US11792001B2 (en) 2021-01-28 2023-10-17 Capital One Services, Llc Systems and methods for secure reprovisioning
US11438329B2 (en) 2021-01-29 2022-09-06 Capital One Services, Llc Systems and methods for authenticated peer-to-peer data transfer using resource locators
US11777933B2 (en) 2021-02-03 2023-10-03 Capital One Services, Llc URL-based authentication for payment cards
US11637826B2 (en) 2021-02-24 2023-04-25 Capital One Services, Llc Establishing authentication persistence
US12143515B2 (en) 2021-03-26 2024-11-12 Capital One Services, Llc Systems and methods for transaction card-based authentication
US11245438B1 (en) 2021-03-26 2022-02-08 Capital One Services, Llc Network-enabled smart apparatus and systems and methods for activating and provisioning same
US12160419B2 (en) 2021-04-15 2024-12-03 Capital One Services, Llc Authenticated messaging session with contactless card authentication
US11961089B2 (en) 2021-04-20 2024-04-16 Capital One Services, Llc On-demand applications to extend web services
US11935035B2 (en) 2021-04-20 2024-03-19 Capital One Services, Llc Techniques to utilize resource locators by a contactless card to perform a sequence of operations
US11902442B2 (en) 2021-04-22 2024-02-13 Capital One Services, Llc Secure management of accounts on display devices using a contactless card
US11354555B1 (en) 2021-05-04 2022-06-07 Capital One Services, Llc Methods, mediums, and systems for applying a display to a transaction card
US12041172B2 (en) 2021-06-25 2024-07-16 Capital One Services, Llc Cryptographic authentication to control access to storage devices
US12061682B2 (en) 2021-07-19 2024-08-13 Capital One Services, Llc System and method to perform digital authentication using multiple channels of communication
US12062258B2 (en) 2021-09-16 2024-08-13 Capital One Services, Llc Use of a payment card to unlock a lock
CN115996122A (zh) * 2021-10-20 2023-04-21 华为技术有限公司 访问控制方法、装置及系统
US12069173B2 (en) 2021-12-15 2024-08-20 Capital One Services, Llc Key recovery based on contactless card authentication
US12166750B2 (en) 2022-02-08 2024-12-10 Capital One Services, Llc Systems and methods for secure access of storage
US12147983B2 (en) 2023-01-13 2024-11-19 Capital One Services, Llc Systems and methods for multi-factor authentication using device tracking and identity verification
US12248832B2 (en) 2023-03-07 2025-03-11 Capital One Services, Llc Systems and methods for steganographic image encoding and identity verification using same
US12248928B2 (en) 2023-03-13 2025-03-11 Capital One Services, Llc Systems and methods of secure merchant payment over messaging platform using a contactless card
US12124903B2 (en) 2023-03-16 2024-10-22 Capital One Services, Llc Card with a time-sensitive element and systems and methods for implementing the same
US12200135B2 (en) 2023-06-13 2025-01-14 Capital One Services, Llc Contactless card-based authentication via web-browser
CN116992419B (zh) * 2023-09-28 2024-01-02 江西省信息中心(江西省电子政务网络管理中心、江西省信用中心、江西省大数据中心) 地图服务共享权限控制方法、系统、电子设备及存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120084565A1 (en) * 2010-09-30 2012-04-05 Microsoft Corporation Cryptographic device that binds an additional authentication factor to multiple identities
WO2014005148A1 (fr) * 2012-06-29 2014-01-03 Id Dataweb, Inc. Système et procédé servant à l'établissement et à la monétisation d'identités sécurisées dans le cyberespace comprenant un service de données personnelles et une console utilisateur

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120084565A1 (en) * 2010-09-30 2012-04-05 Microsoft Corporation Cryptographic device that binds an additional authentication factor to multiple identities
WO2014005148A1 (fr) * 2012-06-29 2014-01-03 Id Dataweb, Inc. Système et procédé servant à l'établissement et à la monétisation d'identités sécurisées dans le cyberespace comprenant un service de données personnelles et une console utilisateur

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
BJONES RONNY ET AL: "Integrating Anonymous Credentials with eIDs for Privacy-Respecting Online Authentication", 10 October 2012, CORRECT SYSTEM DESIGN; [LECTURE NOTES IN COMPUTER SCIENCE; LECT.NOTES COMPUTER], SPRINGER INTERNATIONAL PUBLISHING, CHAM, PAGE(S) 111 - 124, ISBN: 978-3-540-72913-6, ISSN: 0302-9743, XP047265617 *

Also Published As

Publication number Publication date
WO2017042375A1 (fr) 2017-03-16

Similar Documents

Publication Publication Date Title
FR3041195A1 (fr) Procede d'acces a un service en ligne au moyen d'un microcircuit securise et de jetons de securite restreignant l'utilisation de ces jetons a leur detenteur legitime
EP3547203A1 (fr) Méthode et système de gestion d'accès à des données personnelles au moyen d'un contrat intelligent
WO2011138558A2 (fr) Procede d'authentification d'un utilisateur requerant une transaction avec un fournisseur de service
EP1549011A1 (fr) Procédé et système de communication entre un terminal et au moins un équipment communicant
WO2011117486A1 (fr) Infrastructure non hierarchique de gestion de bi-cles de securite de personnes physiques
WO2013021107A1 (fr) Procede, serveur et systeme d'authentification d'une personne
EP3241137B1 (fr) Procede mis en oeuvre dans un document d'identite et document d'identite associe
WO2009019298A1 (fr) Système d'information et procédé d'identification par un serveur d'application d'un utilisateur
WO2017081208A1 (fr) Procede de securisation et d'authentification d'une telecommunication
EP2509025A1 (fr) Procédé d'accès à une ressource protégée d'un dispositif personnel sécurisé
EP3923542A1 (fr) Dispositif informatique et procédé pour l'authentification d'un utilisateur
WO2017114809A1 (fr) Deuxieme authentification dynamique d'une signature electronique utilisant un module materiel securise
EP1514377A1 (fr) Procede et dispositif d'interface pour echanger de maniere protegee des donnees de contenu en ligne
EP2215800A1 (fr) Procede d'authentification d'un utilisateur accedant a un serveur distant a partir d'un ordinateur
FR3030817A1 (fr) Procede d'authentification d'un utilisateur, module securise, appareil electronique et systeme associes
CA2831167C (fr) Infrastructure non hierarchique de gestion de bi-cles de securite de personnes physiques ou d'elements (igcp/pki)
EP3673633A1 (fr) Procédé d'authentification d'un utilisateur auprès d'un serveur d'authentification
WO2017005644A1 (fr) Procédé et système de contrôle d'accès à un service via un média mobile sans intermediaire de confiance
Gestin Privacy-preserving and fully distributed identity management systems
FR2898423A1 (fr) Procede securise de configuration d'un dispositif de generation de signature electronique.
EP1989819B1 (fr) Procéde de certification de clé publique par un prestataire non accrédité
FR3141538A1 (fr) Procede et dispositif de stockage en ligne reparti de fichiers dans un contexte zero confiance
FR2927750A1 (fr) Terminal de paiement electronique pour l'echange de donnees securise sur un reseau ouvert
FR2971350A1 (fr) Procede et dispositif de connexion a un service distant depuis un dispositif hote
EP2630746A1 (fr) Procede et systeme d'authentification

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20170317

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

ST Notification of lapse

Effective date: 20200910