FR2975518A1 - Procede de securisation d'une architecture d'authentification, dispositifs materiels et logiciels correspondants - Google Patents

Abstract

La présente invention concerne un procédé de sécurisation d'une architecture d'authentification et les dispositifs matériels et logiciels pour sa mise en œuvre. Le procédé comporte une phase de création d'une identité par un serveur d'identité, et une phase d'utilisation de cette identité avec un serveur d'authentification. Selon l'invention ces opérations sont sécurisées par un composant sécurisé (typiquement un microcontrôleur sécurisé). Un logiciel, nommé Agent Utilisateur, exécuté sur le terminal de l'internaute, permet d'échanger des données entre les trois entités : navigateur WEB, serveur et composant sécurisé. Un utilisateur d'Internet associé à un navigateur est authentifié par une mutuelle authentification réalisée entre un composant sécurisé (typiquement microcontrôleur sécurisé) et un serveur WEB.

Description

PROCEDE DE SECURISATION D'UNE ARCHITECTURE D'AUTHENTIFICATION, DISPOSITIFS MATERIELS ET LOGICIELS CORRESPONDANTS

Domaine de l'invention

La présente invention se rapporte au domaine des Technologies de l'Information et de la Communication.

La présente invention se rapporte plus particulièrement à un procédé de sécurisation d'une architecture d'authentification, à des dispositifs matériels et aux logiciels correspondants.

15 Etat de la technique

L'authentification des internautes sur le WEB est un aspect fondamental de la sécurité des services numériques disponibles sur Internet tels que le 20 commerce électronique (eCommerce) ou la connexion à des ressources de type Cloud Computing.

Dans l'état actuel de l'art, l'identité d'un internaute est généralement un couple de données identifiant (login) / mot de passe, parfois renforcé à l'aide 25 d'un dispositif nommé One Time Password (OTP) dans la terminologie anglo-saxonne.

L'usage généralisé de mots de passe pour accéder à des services internet est sujet à des attaques qualifiées de phishing, qui ont pour but 30 d'obtenir cette information en reproduisant fidèlement l'aspect d'un site WEB, en particulier le formulaire utilisé pour le renseignement du couple identifiant (login) mot de passe. 10 Une autre contrainte pour l'internaute est la définition et la mémorisation de multiples mots de passe. Les technologies dites de Single Sign On (SSO) ou de fédérations d'identités, ont pour objectif de réduire le nombre d'identifiants requis par les services Internet. Cependant il est évident que l'existence d'un mot de passe unique pour l'accès à de multiples ressources numériques augmente le risque de piratage via des logiciels malveillants (chevaux de Troie) ou procédés de phishing.

Plateforme de Single Sign On OpenlD est un standard ouvert, décrit par exemple par le site http://openid.net, qui définit une solution efficace au problème de l'authentification unique. Il consiste en une authentification décentralisée, déléguée à des entités nommées Serveurs OpenlD et qui ne dépend pas du fournisseur de services sur lequel l'utilisateur souhaite s'authentifier. L'infrastructure OpenlD repose ainsi sur les trois éléments suivants, illustrés par la Figure 1: l'utilisateur (101), le fournisseur de services (102), et le serveur OpenlD lui-même (103). Les méthodes d'authentification sont multiples et dépendent des serveurs OpenlD. Elles sont basées sur des couples login / mot de passe, ou sur des méthodes plus robustes impliquant par exemple l'utilisation de carte à puce ou de biométrie.

La première étape de l'architecture OpenlD implique l'enregistrement d'un utilisateur avec un serveur OpenlD. Une fois le compte créé, il reçoit un identifiant OpenlD spécifique à ce compte sous la forme d'un XRI (eXtensible Resource Identifier), dans lequel apparaît l'adresse du serveur OpenlD. Selon l'état de l'art actuel cette opération est protégée par une session HTTPS, l'authenticité du serveur repose sur la vérification par l'utilisateur (par le navigateur WEB qu'il utilise en fait) de la validité du certificat X509 du serveur.

Au terme de cette première étape, les trois éléments constitutifs de la plateforme OpenlD interagissent de la manière suivante, illustrée par la figure 1.

L'utilisateur qui souhaite s'authentifier auprès d'un fournisseur de services sélectionne (lorsque celle-ci est disponible) l'option d'authentification par protocole OpenlD. Il renseigne son identifiant OpenlD (flèche 1). L'utilisateur est redirigé (au sens HTTP, par exemple à l'aide d'un javascript exécuté automatiquement) vers le serveur OpenlD correspondant à cet identifiant (flèche 3), et s'authentifie selon la méthode disponible sur ce serveur (flèche 4), qui est indépendante du fournisseur de services. Toutefois, les spécifications PAPE (Provider Authentication Policy Extension) établies en 2008 permettent au fournisseur de services d'exiger certaines méthodes 1 o d'authentification de la part des serveurs OpenlD, sous réserve de quoi l'authentification peut être refusée par le fournisseur de services.

Lorsque l'authentification est effectuée (flèche 5), l'utilisateur est redirigé (au sens HTTP, par exemple en utilisant un statut de réponse 302) vers le 15 fournisseur de services (flèche 6). L'identité de l'utilisateur est un ensemble d'information encapsulé dans un formulaire HTML (104) et signé à l'aide d'un secret symétrique (au moyen d'une procédure HMAC, RFC 2104) partagé entre le fournisseur de service et le serveur d'authentification. Cet ensemble est très similaire à la notion de jeton d'authentification définit par le standard SAML 20 (Security Assertion Markup Language). La confidentialité de ces données, est cruciale, puisque l'internaute prouve son identité au fournisseur de service grâce à ce formulaire; le procédé décrit dans cette invention garantie avantageusement la confidentialité entre le terminal de l'internaute et le serveur OpenlD. 25 La sécurité du lien entre le serveur OpenlD et le fournisseur de services réside dans la génération d'un secret partagé entre ces deux entités (flèche 2) lors de la demande d'authentification de l'utilisateur avec le fournisseur de services (avant sa redirection vers l'interface d'authentification du serveur 30 OpenID). Une fois l'authentification réalisée, l'utilisateur est redirigé vers le fournisseur de services avec un en-tête HTTP correspondant au résultat de cette authentification, signé avec une procédure HMAC et le secret partagé, ce qui établit un lien de confiance entre ces trois entités, alors que le fournisseur de services et le serveur OpenlD n'ont a priori aucun lien de confiance préalable.

L'architecture OpenlD réalise également l'authentification unique (Single Sign On).

Problèmes de sécurité du standard OpenlD

La simplicité d'utilisation de l'architecture OpenlD, du point de vue de l'utilisateur comme des fournisseurs de services, induit de véritables questionnements quant aux garanties de sécurité qu'elle offre. Ces questions de sécurité sont d'autant plus vitales dans le cadre du service d'authentification unique proposé par OpenlD, où un attaquant peut gagner accès à plusieurs services à la fois en ayant usurpé un seul compte.

Or, la seule sécurité garantie par OpenlD est celle de la validité du résultat de l'authentification auprès du serveur OpenlD, qui est transmis au fournisseur de services signé par le secret partagé et la procédure HMAC. Les spécifications PAPE de 2008 laissent la liberté au fournisseur de services d'exiger des méthodes d'authentification fortes (par exemple à base de PKI et/ou de biométrie), mais il n'y a aucune garantie qu'un fournisseur de service mette en place ces spécifications afin d'exiger une sécurité forte. Il n'y a également aucune obligation, dans les spécifications OpenlD d'implémenter ces méthodes fortes. De fait, la majorité des serveurs OpenlD existants se limitent à proposer une authentification de type identifiant / mot de passe, c'est-à-dire d'un niveau de sécurité très faible.

Les attaques contre les serveurs OpenlD usuels peuvent donc être menées d'une manière extrêmement classique, soit par recherche du mot de passe utilisateur, soit par phishing. Ces considérations montrent qu'en l'état, l'architecture OpenlD a besoin d'augmenter ses garanties de sécurité. L'utilisation du protocole SSLITLS pourrait ainsi être rendu obligatoire pour tout serveur OpenlD. Cela serait un pas en avant contre les attaques par phishing, mais le protocole SSL/TLS est encore insuffisant à assurer cette sécurité de manière satisfaisante, car les utilisateurs sont habitués à des sites dont les certificats sont invalides sans qu'il s'agisse pour autant de sites fallacieux, et sont ainsi prompts à négliger les avertissements dus à des certificats impropres. De plus, SSL/TLS n'est pas satisfaisant au niveau de l'authentification de l'utilisateur, car l'authentification mutuelle est rarement pratiquée. Par conséquent, la simple mise en place de SSL/TLS ne permet pas d'éliminer les attaques sur les mots de passe des utilisateurs. Ces attaques peuvent être extrêmement faciles à réaliser selon le degré de sécurisation du serveur. Une attaque par dictionnaire est souvent efficace car les utilisateurs 1 o choisissent très souvent des mots de passe simples à retenir, mais d'autres types d'attaques, notamment les attaques classiques contre les applications Web (Cross Site Scripting - XSS, par exemple), permettent d'obtenir les identifiants des utilisateurs sans avoir à surcharger le serveur de requêtes - ce qui est peu discret et peut aisément faire l'objet de contre-mesures sécuritaires. 15 Afin de combler les failles potentielles de l'architecture OpenlD, il convient donc de déployer une méthode d'authentification forte - consistant notamment à éviter l'utilisation de couples identifiant / mot de passe - ainsi qu'à éliminer toute attaque par phishing sur le serveur. Il s'agit donc d'une 20 sécurisation de l'architecture qui maximise la sécurité tout en respectant les standards de I'Internet. Une telle sécurité implique l'utilisation de composants sécurisés tels que des cartes à puce afin de stocker des éléments sensibles de manière sûre (contrairement au stockage sur ordinateur qui ne l'est pas du fait d'un trop grand nombre d'ouvertures et de l'absence de protections physiques 25 et logiques).

Par ailleurs, un serveur OpenlD propose à ses utilisateurs la création et la gestion d'identités qui peuvent être utilisées pour s'authentifier auprès de fournisseurs de services. Par conséquent, une solution de sécurisation de 30 l'architecture globale doit être compatible avec cette contrainte, notamment en stockant les identités générées dans le composant sécurisé.

On connaît dans l'état de la technique les publications scientifiques suivantes : « Convergent identity : Seamless OPENID services for 3G dongles using SSL enabled USIM smart cards » de Pascal URIEN (Consumer Communications and Networking Conference - CCNC - 2011 - IEEE - 9 janvier 2011) ; - " An OpenlD provider based on SSL smart cards" de Pascal URIEN (Consumer Communications and Networking Conference - CCNC - 2010 - IEEE - 9 janvier 2010) ; et " TLS-Tandem : a smart card for Web applications » de Pascal URIEN (Consumer Communications and Networking Conference - CCNC - 2009 - IEEE - 10 janvier 2009). L'art antérieur connaît également, par la demande de brevet français N° FR 2 791 159 (BULL CP8), un procédé d'accès à un objet à l'aide d'un navigateur de type « Web » coopérant avec une carte à puce, et une architecture pour la mise en oeuvre du procédé.

Exposé de l'invention

La présente invention concerne un procédé d'authentification qui résiste au phishing, et sa mise en oeuvre dans le contexte de la fédération d'identité, avec l'exemple non limitatif de la norme OpenlD. La plateforme d'authentification décrite par l'invention comporte quatre éléments.

1- Un composant matériel sécurisé, couramment un composant (typiquement microcontrôleur) sécurisé (qualifié de «tamper resistant device», ou encore de «secure element») qui exécute un logiciel intégrant le protocole TLS/SSL dans un environnement sécurisé physiquement et logiquement.

2- Un logiciel nommé Agent Utilisateur (User Agent) qui réalise l'interface (la glue logique) entre le navigateur Internet (Browser) et le composant (typiquement microcontrôleur) sécurisé. 3- Un serveur d'identité qui génère des identités et gère leur cycle de vie. Ces informations sont téléchargées via internet dans des structures de données sécurisés, dénommées container dans ce document, qui ne peuvent être déchiffrés que par le composant sécurisé (typiquement un microcontrôleur sécurisé). 4- Un serveur d'authentification de type Single Sign On, par exemple un serveur OpenlD, qui dialogue via le Agent Utilisateur (User Agent) avec le composant (typiquement microcontrôleur) sécurisé.

1 o A cet effet, la présente invention concerne, dans son acception la plus générale, une plateforme d'authentification comportant : - un serveur d'identité, - un serveur d'authentification, - un terminal informatique adapté à exécuter un logiciel, 15 ledit logiciel permettant l'échange de données entre : - un serveur (d'identité ou d'authentification), - un composant sécurisé, - et un navigateur disponible sur un terminal (ordinateur personnel, téléphone mobile) d'un client, 20 ladite plateforme d'authentification étant caractérisée en ce que ledit composant sécurisé (typiquement microcontrôleur sécurisé) exécute de manière autonome le protocole SSL ou TLS, et réalise un protocole Handshake lors de l'ouverture d'une session SSL/TLS entre le terminal du client et le serveur d'identité, ledit composant sécurisé étant fabriqué avec 25 un premier certificat et une clé privée, et en ce qu'elle comporte en outre des moyens pour télécharger à partir du serveur d'identité, un ensemble de données chiffré avec la clé publique présente dans le certificat du composant sécurisé, et signé avec une clé privée d'une autorité de certification reconnue par le composant, en 30 mettant en oeuvre une session SSL/TLS ouverte par le composant sécurisé.

Selon un mode de réalisation, ledit serveur d'identité comporte des moyens pour collecter le certificat dudit composant sécurisé.

Avantageusement, ledit serveur d'identité comporte des moyens pour extraire du certificat dudit composant sécurisé sa clé publique.

Selon un mode de réalisation, ledit serveur comporte des moyens pour construire un containeur sécurisé comportant : - un entête chiffré avec la clé publique du composant sécurisé ; un container d'identité chiffré avec une clé 1 o symétrique renseignée dans l'entête chiffrée ; et - une signature numérique produite par une clé privée appartenant à un tiers de confiance identifié par la clé publique associée. De préférence, ledit composant sécurisé comporte des moyens pour 15 analyser ledit containeur sécurisé.

Selon un mode de réalisation, ledit composant sécurisé comporte des moyens pour : - vérifier ladite signature avec une clé publique du tiers 20 de confiance, stockée dans le composant sécurisé ; - déchiffrer l'entête avec la clé privée dudit composant sécurisé ; et - décrypter le containeur sécurisé chiffré. Avantageusement, ledit composant sécurisé comporte en outre des 25 moyens pour interpréter des informations contenues dans le containeur sécurisé décrypté.

De préférence, lesdites informations comprennent l'identité SSL en clair.

30 La présente invention se rapporte également à une plateforme d'authentification comportant : - un serveur d'identité, - un serveur d'authentification, - un terminal informatique adapté à exécuter un logiciel, ledit logiciel permettant l'échange de données entre : - un serveur (d'identité ou d'authentification), - un composant sécurisé, - et un navigateur disponible sur un terminal (ordinateur personnel, téléphone mobile) d'un client, ladite plateforme d'authentification étant caractérisée en ce que ledit composant sécurisé (typiquement microcontrôleur sécurisé) exécute de manière autonome le protocole SSL ou TLS, et réalise un protocole Handshake lors de l'ouverture d'une session SSL/TLS entre le terminal du client et le serveur d'authentification, ledit composant sécurisé étant fabriqué avec un premier certificat et une clé privée, et en ce qu'elle comporte en outre des moyens pour télécharger à partir du serveur d'authentification, un ensemble de données chiffré avec la clé publique présente dans le certificat du composant sécurisé et signé avec une clé privée d'une autorité de certification reconnue par le composant, en mettant en oeuvre une session SSL/TLS ouverte par le composant sécurisé.

Brève description des dessins On comprendra mieux l'invention à l'aide de la description, faite ci-après à titre purement explicatif, d'un mode de réalisation de l'invention, en référence aux Figures dans lesquelles :30 - La Figure 1 illustre la structure typique d'une plateforme d'authentification OpenlD, qui comporte l'utilisateur (101), le fournisseur de services (102), et le serveur OpenlD lui-même (103). - La Figure 2 présente brièvement le déroulement de l'ouverture dune session SSL/TLS à l'aide d'un composant sécurisé. Le navigateur WEB envoie une requête d'ouverture de connexion au proxy du poste client (201), qui la transmet au composant embarquant la pile SSL/TLS (202). Le Client Hello du Handshake est alors généré par le composant puis transmis au serveur (203) par l'intermédiaire du proxy. Une fois la phase lo de Handshake terminée la session est transférée sur le terminal. - La Figure 3 décrit le cycle de vie de l'identité du composant sécurisé. Elle comporte une phase de fabrication, l'émission du composant et sa gestion par son utilisateur. - La Figure 4 illustre la structure d'un container chiffré d'identité. Ce 15 dernier est constitué d'un en-tête chiffré avec la clé publique du composant sécurisé, d'une section de données d'identité chiffrées à l'aide d'une clé symétrique, et d'une signature asymétrique. - La Figure 5 représente le procédé de sécurisation d'une plateforme d'authentification OpenlD. Ce dernier est mis en oeuvre grâce à un 20 composant sécurisé, typiquement un microcontrôleur sécurisé (501), un logiciel Agent Utilisateur, User Agent (502) exécuté sur un terminal (PC, smartphone, ...), un serveur d'identité (503), et un serveur d'authentification OpenlD (504). - La Figure 6 détaille la structure logique d'un Agent Utilisateur (User 25 Agent) sous forme d'un logiciel proxy, comportant un socket serveur et un socket client. - La Figure 7 illustre la structure logique d'un Agent Utilisateur (User Agent) sous forme d'un applet WEB utilisant les paquetages et classes netscape.javascript.JSObject, Socket, et javax.smartcardio. 30 Description détaillée des modes de réalisation de l'invention

La présente invention réalise une sécurisation globale d'une architecture d'authentification telle que OpenlD, tout en assurant la gestion des identités.

Elle se compose de quatre entités, décrites à la Figure 5, un composant sécurisé, typiquement un microcontrôleur sécurisé (501), un logiciel Agent Utilisateur ou User Agent (502) exécuté sur un terminal (PC, smartphone, ...), un serveur d'identité (503), et un serveur d'authentification OpenlD (504).

1 o Le composant sécurisé

Un composant sécurisé, typiquement un microcontrôleur sécurisé, est un composant électronique durci d'un point de vue sécuritaire tant du point de vue physique que logique, tels que les références actuelles ST22 ou ST23 de la 15 société STMicroelectronics, Smart MX (PN532), ..) de la société NXP, SLE66 ou SLE68 de la société Infineon. Dans le cadre de cette invention ces composants (typiquement microcontrôleurs) embarquent une implémentation du protocole SSL/TLS, usuellement dénommée pile SSL/TLS ou «stack» dans la terminologie Anglo-Saxonne. 20 Il est à noter que le terme composant (typiquement microcontrôleur) sécurisé est utilisé dans ce document dans un sens large, représentatif de tout composant, circuit intégré, permettant de réaliser le traitement d'opérations élémentaires suivant une séquence donnée. Cela inclut donc des composants 25 de type FPGA, microprocesseurs ou DSP... Sans que cette liste soit exhaustive.

Les composants (typiquement microcontrôleur) sécurisés utilisent généralement un format de commandes défini par la norme ISO7816, 30 représenté par le sigle APDU (Application Protocol Data Unit).

Secure Sockets Layer (SSL), est un protocole de sécurisation des échanges sur Internet, développé par la société Netscape avec deux versions majeures SSL version 2 et SSL version 3. Depuis 2001 il est normalisé par l'IETF (www.ietf.org) sous le sigle TLS (Transport Layer Security) par les RFC 2246, RFC 4346, RFC 5246, RFC 4347. Dans ce document les termes SSL et TLS se réfèrent à ces différents standards.

Cette implémentation est réalisée de telle sorte que la taille du code (de l'ordre de quelques dizaines de KiloOctets) puisse tenir dans la mémoire non volatile des composants les plus petits. Elle peut être intégrée à tout type de composant (typiquement microcontrôleur) sécurisé, que ce soit une carte SIM, une JavaCard, un composant NFC, un processeur SmartMX. Contrairement 1 o aux données stockées sur un support informatique classique de type disque dur ou mémoire FLASH, les composants (typiquement microcontrôleur) sécurisés bénéficient de contre-mesures physiques et logiques qui rendent très difficile la lecture ou la modification non autorisées de données.

15 Le composant sécurisé agit comme un client SSL/TLS, intégré logiquement au terminal client afin de décharger le terminal de la réalisation du Handshake SSL/TLS. Ainsi, lorsqu'un utilisateur souhaite se connecter via son navigateur à un serveur WEB en SSL/TLS (c'est-à-dire HTTPS), l'établissement de la session (le protocole Handshake) est intégralement réalisé par le 20 composant sécurisé.

La pile SSL/TLS est implémentée sur la forme d'une machine à états, aussi bien en mode «full» qu'en mode «resume» (encore dénommé «abbreviated»), dans laquelle tous les calculs cryptographiques du protocole 25 Handshake de SSL/TLS sont effectués dans le composant. Ces calculs comprennent de la cryptographie asymétrique (RSA, Diffie-Hellman, Courbes Elliptiques) symétriques (RC4, DES, 3xDES, AES...) et des fonctions de hachage (SHA1, SHA256, MD5, HMAC...). Le «Master Secret» de la session SSL/TLS est ainsi directement calculé et stocké dans le composant sécurisé. 30 Par ailleurs, les paquets SSL/TLS peuvent être avantageusement encapsulés via le protocole EAP, selon les spécifications de la norme EAP-TLS (RFC 2716, RFC 5216), assurant ainsi un transport des paquets en mode datagramme et conférant ainsi une sécurité accrue.

La norme EAP-TLS impose par ailleurs une authentification mutuelle entre client et serveur (le client s'authentifie à l'aide du message Verify). Le certificat X509 client est stocké dans un Container d'identité (détaillé en section 3-C) sur le composant sécurisé, ainsi que sa clé privée.

Une fois la phase de Handshake achevée, les valeurs des clés éphémères contenues dans le "KeyBlocks" et dérivées du Master Secret peuvent être ou non exportées sur le terminal client, de sorte que le chiffrement symétrique de la session SSL/TLS peut être réalisé soit par le composant sécurisé, soit le terminal en fonction des besoins de l'application. Ce choix ne modifie pas le procédé de sécurisation de la plateforme OpenlD décrit dans ce document.

Une pile SSL/TLS embarquée de manière avantageuse dans un composant sécurisé permet, par la nature de ce dernier, de prévenir les failles d'implémentation logicielle de SSL/TLS présentes habituellement sur les terminaux clients, et évite ainsi une modification potentielle du code de cette dernière ou la récupération de données sensibles par un tiers, ou un logiciel malveillant (malware) tel qu'un cheval de Troie.

L'Agent Utilisateur (User Agent)

Le logiciel Agent Utilisateur (User Agent) réalise la «glue logique» (interface logique) entre un serveur WEB (serveur d'identité ou serveur OpenID) et le composant (typiquement microcontrôleur) sécurisé. Il est exécuté dans un terminal informatique tel qu'ordinateur personnel, tablette ou smartphone, sous la supervision de systèmes d'exploitation variés (Windows, Android, RIM, Apple, Linux, ...).

Il réalise la communication entre le terminal client, équipé d'un navigateur WEB et le composant sécurisé, mais également le lien entre le composant (typiquement microcontrôleur) sécurisé et le serveur WEB lors d'une connexion SSL/TLS.

Le logiciel User Agent est compatible avec toutes sortes d'interfaces physiques et logiques vers le composant sécurisé, notamment bus USB, PC/SC, AT-CSIM, port série, sans contact: NFC, BLUETOOTH, Wi-Fi,, sans que cette liste soit limitative. Ainsi, les composants (typiquement microcontrôleurs) sécurisés peuvent communiquer de manière transparente vers un serveur WEB pour établir une session SSLITLS. Le code source de la pile SSL/TLS est adapté à chaque type d'interface, par exemple en utilisant des tailles variables de paquets EAP. Le logiciel Agent Utilisateur (User Agent) peut être réalisé au moyen d'un logiciel proxy (basé sur la bibliothèque Socket pour TCP/IP), ou sous d'autres formes telles qu'un APPLET Java téléchargé et exécuté dans un navigateur Internet. Dans la suite de ce document, les architectures correspondant à ces deux exemples seront détaillées, sans que ces exemples constituent une limitation pour l'implémentation du logiciel Agent Utilisateur (User Agent).

La Figure 6 illustre la structure logique d'un Agent Utilisateur (User Agent) «proxy». Le User Agent (602) gère un socket serveur (604) qui réalise l'interface avec le navigateur WEB (601), et un socket client (605) qui établit une connexion TCP avec un serveur distant (603). Il gère également un port de communication avec le composant (typiquement microcontrôleur) sécurisé (606) qui peut ainsi échanger des données avec le navigateur (601) et le serveur (603).

La Figure 7 présente la structure logique d'un Agent Utilisateur (User Agent) «APPLET Java». Le navigateur WEB (701) télécharge une page HTML contenant un APPLET (702) signé (par exemple avec l'outil jarsigner) et stocké sur un serveur (703). Cet APPLET établit des connexions TCP avec le serveur (703) à l'aide d'un socket client fourni par la classe JAVA Socket; il peut également échanger des informations avec le composant (707) sécurisé (typiquement microcontrôleur) au moyen de la classe javax.smartcardio (706) disponible à partir de la version 1.6 du langage JAVA. La classe netscape.javascript.JSObject supporté par la plupart des navigateurs WEB permet d'exécuter un JavaScript associé à la page HTML chargé par le navigateur (à l'aide de la méthode netscape.javascript.JSObject.eval), et en particulier d'effectuer une redirection HTTP après avoir inséré un cookie.

Le logiciel User Agent convertit des requêtes HTTP particulières en une 5 suite de commandes APDUs, définies par le standard ISO 7816, par exemple l'URL

http://127.0.0.1:8080/-apdu?=cmd1&=cmd2...&=cmdn

1 o est interprété par un Agent Utilisateur (User Agent) comme une succession de (n) commandes APDUs (cmdi, cmd2, cmdn) transmises au composant (typiquement microcontrôleur) sécurisé. Les réponses à ces commandes sont retournées au format HTML ou XML.

15 Afin de réaliser les ouvertures de connexion SSL/TLS par l'intermédiaire de l'Agent Utilisateur (dans ce cas «proxy»), l'URL exécutée par un navigateur WEB possède un format spécifique, du type :

http://127.0.0.1:8080/-url=serveur.com 20 Ainsi, comme le montre la Figure 2, le navigateur WEB envoie une requête d'ouverture de connexion au «User Agent» (dans ce cas «proxy») du poste client (201), qui la transmet (flèche 1) au composant embarquant la pile SSL/TLS (202). Le Client Hello du Handshake est alors généré par le 25 composant puis transmis au serveur (203) par l'intermédiaire du proxy. La suite du Handshake est alors réalisée directement entre le composant sécurisé et le serveur, via le «User Agent» (dans ce cas «proxy») (flèche 2), qui ne prend pas en compte les retransmissions des paquets SSL/TLS vers le «User Agent» (dans ce cas «proxy») qui n'a qu'un rôle d'intermédiaire. 30 Dans le cas où les clés temporaires de session sont exportées sur le poste client (flèche 3), le composant n'intervient plus dans la suite de la session SSL/TLS, à savoir la phase d'échange de données cryptées (flèche 4) entre client et serveur. Sinon, c'est ce dernier qui réalise les calculs cryptographiques nécessaires à l'échange de données chiffrées.

L'une des alternatives possibles à l'utilisation d'un proxy, qui permet notamment de gérer avantageusement les cookies de session lors de l'authentification sur un serveur WEB, est un Applet Java délivrant les mêmes services que le proxy. C'est alors l'Applet qui fait l'interface avec le composant sécurisé et le navigateur, grâce par exemple à la classe netscape.javascript.JSObject disponible sur les navigateurs WEB, qui permet 1 o d'exécuter des javacripts embarqués sur une page HTML, et peut être instancié selon le procédé dénommé "Java Reflection".

Le composant sécurisé embarquant la pile SSL/TLS stocke également une identité, qui peut être de type «client» ou «serveur», c'est-à-dire réalisant le 15 protocole SSL/TLS côté client ou côté serveur. Dans le cas d'une authentification sur un serveur WEB standard, cette identité sera de type «client», mais d'autres applications peuvent nécessiter une identité de type «serveur», notamment dans le contexte de l'Internet des Objets (Internet Of Things) et des applications par exemple M2M (Machine à Machine). Dans la 20 suite de ce document, nous supposerons que l'identité utilisateur est de type «client».

Le format de cette identité (aussi appelée Container d'identité dans ce document) est décrit ci-dessous. Cette identité contient, entre autres éléments, 25 le certificat de l'utilisateur et la clé privée associée. Cette identité peut être générée par des outils tels que OpenSSL, puis chargée dans le composant sécurisé par l'intermédiaire d'APDUs dédiés ou standards (telles que la commande d'écriture en mémoire non volatile). Ce chargement peut être réalisé soit de manière locale, via des logiciels gérant l'échange de données avec le 30 composant, soit de manière distante via une interface WEB avec un serveur dédié. L'identité est produite à la demande de l'utilisateur. Celui-ci doit simplement saisir un nom d'utilisateur (son nom ou bien un pseudonyme, par exemple) afin qu'un Container d'identité soit généré, qui contienne un certificat dont, par exemple, l'attribut Common Name corresponde au nom qu'il a saisi auparavant.

L'interface WEB de chargement des identités est construite sur l'utilisation conjointe de l'Agent Utilisateur (User Agent, proxy ou applet WEB) et de la technologie AJAX (Asynchronous Javascript and XML), en particulier la mise en oeuvre de l'API XMLHttpRequest définie par le W3C consortium (http://www.w3.org). En effet, une fois l'identité générée sur le serveur WEB à la demande de l'utilisateur, le Container correspondant est inséré dans une page 1 o munie de fonctionnalités AJAX. Ces dernières permettent de réaliser un chargement transparent de l'identité dans le composant. L'établissement du lien entre le composant et le serveur est réalisé à l'aide de l'Agent Utilisateur (User Agent), qui est la cible de la requête AJAX lancée depuis la page WEB. L'Agent Utilisateur (User Agent) transmet la requête, c'est-à-dire les APDUs, au 15 composant, et analyse la réponse de ce dernier. Si aucun des statuts renvoyés ne fait état d'une erreur dans le traitement des APDUs, l'Agent Utilisateur (User Agent) réémet une réponse HTTP de statut 200, de manière à ce que l'interface AJAX puisse recevoir une réponse et la traiter en conséquence (en affichant par exemple un message de succès de chargement de l'identité). 20 L'interface AJAX émettant une requête directement au proxy (via l'objet XMLHttpRequest), c'est-à-dire à l'hôte local 127.0.0.1, la politique de même origine exige que la page WEB d'où part cette requête appartienne au même domaine. Dans le cas présent, cela signifie que l'utilisateur devra s'être 25 authentifié auparavant afin que la page contenant l'interface AJAX ait une URL du type:

http://127.0.0.1:8080/-url=server.com/download_identity.html.

30 Selon les cas considérés, il peut être possible de stocker une seule ou plusieurs identités sur un composant. Dans le cas où une seule identité est stockée, celle-ci peut être mise à jour (c'est-à-dire supprimée puis réécrite) par cette interface, en utilisant un APDU approprié à cette fin. Dans le cas du stockage de plusieurs identités, on juxtapose plusieurs Containers d'identités dans le composant en générant dynamiquement une adresse d'écriture adéquate dans le composant lors de la génération de l'identité. Dans ce cas, le choix de l'emplacement de l'identité à charger dans le composant peut être proposé à l'utilisateur lors de sa demande de génération d'identité. Le serveur d'identité

Une identité SSL/TLS (encore appelée Container d'identité), telle qu'elle est stockée dans le composant, comporte au moins les champs suivants, 1 o précédés à chaque fois que cela est nécessaire d'un ou de deux octets donnant leur longueur: - Le type de l'identité (client ou serveur), - Le nom associé à l'identité, - L'identifiant (Identity) EAP-TLS (nécessaire en cas de 15 requête EAP.Identity-Request), - et une série de clés nécessaires à l'établissement d'une session SSL/TLS (par exemple la clé privée RSA, et le certificat associé à l'identité).

20 Par ailleurs, les clés publiques des autorités de certification acceptées par le composant doivent avoir été stockées au préalable dans le code du protocole SSL/TLS embarqué.

L'identité racine du composant est un ensemble de paramètres inséré 25 dans la phase de production du composant, qui comporte les éléments suivants: - Le certificat de l'autorité de certification qui génère les certificats acceptés par le composant. - La clé privée asymétrique associé au composant (RSA, 30 ECC) - Le certificat associé à la clé asymétrique publique du composant, délivré par l'autorité de certification, et qui intègre (par exemple dans l'attribut DN) un identifiant unique tel que par exemple numéro de série ou numéro de téléphone.5 Le standard SSL/TLS utilise des certificats au format X509. Cependant de multiples formats peuvent être disponibles dans le composant, sans avoir d'influence sur le procédé décrit dans ce document. Dans le cadre d'un serveur d'identités, la principale fonctionnalité est de pouvoir générer et stocker plusieurs identités différentes pour un seul utilisateur, c'est-à-dire pour un unique composant sécurisé.

1 o Le terme utilisateur désigne un usager humain capable d'interagir avec le logiciel Agent Utilisateur, ou un système informatique échangeant des données à travers une interface de communication (ISO7816, USB, I2C, ISO 14443, NFC...) avec le logiciel Agent Utilisateur stocké dans le composant.

15 A cette fin, il est nécessaire de lier la génération des identités au composant détenu par l'utilisateur, de la manière décrite à la Figure 3. Pour cela, après la réalisation du composant en usine (étape 301), une identité SSL/TLS «racine» est stockée dans le composant, associée à un identifiant unique (numéro de série), ainsi que la clé privée correspondante (étape 302). 20 Lorsque l'utilisateur reçoit son composant (étape 303), il doit s'enregistrer auprès du serveur d'identités à l'aide de son composant et de son certificat «racine». Lors de cette étape, il doit saisir des informations personnelles qui seront associées à son composant, et notamment à son identité «racine» (étape 304). Par la suite, l'utilisateur sera en mesure de générer des identités 25 sur ce serveur, et de les stocker librement dans son composant, à l'exception près qu'il ne pourra jamais effacer ou réécrire l'identité «racine» (étape 305). C'est en effet cette dernière qui contient la clé publique rendant le composant unique, et c'est par cette clé publique que le serveur est en mesure d'associer les identités générées au composant auquel elle est liée. 30 A chaque fois que l'utilisateur souhaite gérer ses identités (création ou destruction, modification d'informations liées aux identités), il doit au préalable s'authentifier sur le serveur d'identités à l'aide de son identité «racine». Toutefois, il peut par la suite, s'il le souhaite, sélectionner une des identités5 présentes dans son composant afin d'en faire l'utilisation auprès d'un serveur WEB pour réaliser une authentification.

Lorsque l'utilisateur souhaite créer une identité, il doit saisir le nom donné à cette identité, et pourra par exemple saisir un numéro qui déterminera l'adresse de stockage de l'identité dans la mémoire non volatile du composant. Les identités présentes dans le composant doivent être répertoriées également sur la base de données du serveur d'identités afin d'assurer la cohérence des actions de l'utilisateur. De manière identique, lorsqu'une identité présente sur le composant est supprimée ou réécrite, le serveur doit être mis à jour en conséquence afin d'être synchronisé avec les données présentes sur le composant de l'utilisateur.

Enfin, dans le cas où l'utilisateur a perdu son composant, il doit signaler cet état de fait aux administrateurs du serveur d'identités (dans le cas où le composant est arrivé en fin de vie, cela sera automatiquement détecté par le serveur), afin que soient révoqués tous les certificats X509 émis lors de la génération des identités SSL/TLS de cet utilisateur. La clé publique de l'identité «racine» du composant est alors placée dans une liste noire (étape 306). Si une tentative de connexion était réalisée à partir de cette identité, celle-ci serait refusée par le serveur d'identité. Toutefois, l'utilisateur peut garder son ancien compte sur le serveur d'identité. En effet, lorsqu'il aura en sa possession un nouveau composant, avec une nouvelle identité «racine», il lui faudra faire la preuve de son identité auprès des administrateurs du serveur, à l'aide des informations personnelles saisies lors de son enregistrement sur le serveur. Si ces dernières sont valides, la nouvelle clé publique du composant pourra être liée à son ancien compte sur ce serveur d'identités.

La sécurité de la gestion des identités chargées depuis le serveur WEB vers le composant sécurisé repose sur l'utilisation d'un chiffrement rendant impossible un chargement illégal d'identité dans le composant. La mise en oeuvre de quelques mécanismes aura pour objet de s'affranchir des possibles effets négatifs suivants : l'architecture décrite précédemment est soumise à plusieurs failles de sécurité potentielles liées à la génération d'un Container d'identité qui est inséré dans une page WEB afin d'être chargé dans le composant via une interface AJAX. Un utilisateur peut donc observer le format du Container et éventuellement utiliser les mêmes APDUs d'écriture dans un autre composant, afin de charger lui-même une identité sans avoir déclaré cette action au serveur. Par ailleurs, il serait possible à l'utilisateur de lancer lui-même des commandes d'écriture en Mémoire non volatile afin de saisir lui-même des informations sur le composant. Enfin, le Container d'identité contient en clair la clé privée de l'identité générée, qui est une information beaucoup trop sensible pour apparaître en clair dans une page WEB, même si on la 1 o positionne dans un champ caché.

Afin de remédier à ces failles, un Container chiffré est généré par le serveur d'identité, de la manière illustrée par la Figure 4.

15 On désigne par «container en clair» un ensemble de données, interprété par le composant sécurisé. Dans la figure 401 cet ensemble nommé « identité SSL», comporte toutes les informations nécessaires pour établir une session SSL/TLS avec mutuelle authentification, c'est-à-dire un certificat X509 et la clé privée associée, le certificat de l'autorité de certification, ainsi que divers 20 paramètres dont en particulier un alias de l'identité SSL.

Le container en clair est chiffré par un algorithme cryptographique symétrique, par exemple AES, à l'aide d'une clé (nommée K sur la figure 401) dont la valeur est établie de manière aléatoire. Un chiffrement en mode bloc 25 (cipher block) utilise des longueurs de données multiple d'un nombre entier (par exemple 16 octets pour AES), le container chiffré possède donc une longueur qui peut être supérieure à celle du container en clair, selon une technique basée sur des octets dits de bourrage (padding) ajoutés sous forme de suffixe.

30 La clé de chiffrement (K) est insérée dans un entête (402), qui contient également plusieurs informations telles que la nature de l'algorithme de chiffrement utilisé, la longueur du container en clair, et l'algorithme de signature utilisé.

Lors de l'établissement de la session SSL/TLS entre le composant sécurisé et le serveur, ce dernier a collecté le certificat du composant sécurisé qui contient la clé publique Kpub. Cette clé permet de réaliser le chiffrement asymétrique de l'entête 402 (par exemple via l'algorithme RSA) selon des procédés standardisés tels que PKCS#1. En l'état de l'art actuel, seule la connaissance de la clé privé Kpriv (stockée dans le composant sécurisé) permet de déchiffrer l'entête 402 crypté. Cependant, la nature publique de la clé Kpub permet à toute entité (éventuellement hostile) de générer des entêtes et des containers chiffrés. Pour 1 o cette raison l'ensemble des données résultant de la concaténation de l'entête chiffrée et du container chiffré est signé (par exemple avec un procédé standardisé tels que PKCS#1) à l'aide d'une clé privée associée à une entité de confiance reconnue par le composant sécurisé. Cette relation repose sur le fait que le composant sécurisé connait la clé publique de l'entité de confiance, et 15 qu'il est en conséquence capable de vérifier cette signature numérique.

En résumé, la délivrance d'un container sécurisé s'appuie sur les éléments suivants - Une mutuelle authentification est réalisée à l'aide d'une 20 session SSL/TLS entre un composant sécurisé et un serveur. En particulier le serveur a collecté le certificat du composant sécurisé. - Le serveur extrait du certificat du composant sécurisé sa clé publique - Le serveur (ou une autre entité) construit un containeur 25 sécurisé comportant trois sous-ensembles 1) Un entête chiffré avec la clé publique du composant sécurisé 2) Un container d'identité chiffré avec une clé symétrique renseignée dans l'entête chiffrée. 30 3) Une signature numérique produite par une clé privée appartenant à un tiers de confiance identifié par la clé publique associée.

Le container sécurisé est analysé par le composant sécurisé selon le scénario suivant : 1) La signature est vérifiée avec la clé publique du tiers de confiance, stockée dans le composant sécurisé. 2) Si l'opération précédente est réalisée avec succès, l'entête est déchiffrée avec la clé privée du composant sécurisé. La nature de l'algorithme de chiffrement symétrique et sa clé sont alors déterminés de même que la taille du container en clair. 3) Le container chiffré est décrypté, ce qui permet 1 o d'obtenir les informations (identité SSL en clair). Ces informations sont alors interprétées par le composant sécurisé.

Le Container en clair (401) est d'abord chiffré par le serveur à l'aide d'une clé d'un algorithme symétrique (par exemple AES). Cette clé est placée 15 dans un en-tête (402) de longueur fixe qui contient par ailleurs plusieurs informations liées à l'identité générée (telles que le nom donné à l'identité, l'emplacement de l'identité dans le composant), ainsi que l'heure Unix de génération du Container. Cet en-tête est chiffré de manière asymétrique à l'aide de la clé publique du composant (la clé publique «racine»), récupérée lors de la 20 connexion au serveur d'identités réalisée par l'utilisateur, et indispensable au déroulement de l'étape de création d'identité.

Enfin, l'en-tête chiffré concaténé avec le Container d'identité chiffré par la clé symétrique est signé numériquement avec la clé privée du serveur 25 d'identités qui joue ici le rôle de l'autorité de certification (CA), par exemple au format PKCS #1. L'ensemble constitue alors le Container chiffré (403) prêt à être envoyé au composant avec des APDUs d'écriture appropriées. En effet, ces APDUs réalisent une écriture dans une adresse virtuelle, ce qui signifie que le contenu du Container chiffré n'est pas directement stocké en clair dans la 30 mémoire non volatile du composant sécurisé. Il doit auparavant être vérifié par le composant. Pour cela, celui-ci vérifie d'abord la signature numérique, puis, si celle-ci est correcte, il déchiffre l'en-tête du Container avec sa clé privée «racine». Il récupère de cet en-tête la clé symétrique utilisée précédemment pour chiffrer l'Identité SSL/TLS qui était en clair à l'origine, puis déchiffre cette dernière. Si l'ensemble des opérations s'est déroulé sans erreur, le Container en clair est alors écrit en mémoire non volatile à l'emplacement sélectionné par l'utilisateur (emplacement stocké notamment dans l'en-tête soumis au composant). En revanche, si une erreur se produit à l'une des étapes précédentes, un statut d'erreur est renvoyé vers le navigateur via l'Agent Utilisateur (User Agent, typiquement le proxy), et le Container d'identité est rejeté sans être écrit en mémoire non volatile.

Le Serveur d'Authentification OpenlD La mise en oeuvre de la plateforme décrite dans les sections précédentes peut s'appliquer à des architectures de fédération d'identités reposant sur la génération et le transport de jetons sécurisés, à la manière d'OpenlD (décrite ci-dessus). En effet, OpenlD fonctionne sur le principe d'un échange de secret entre le fournisseur de services et le serveur OpenlD, ainsi que mentionné ci-dessus. Ce secret est ensuite utilisé pour prouver que l'utilisateur a bien réalisé une authentification sur le serveur OpenlD mentionné dans son identifiant OpenlD. S'il s'avère toutefois que l'utilisateur est parvenu à tricher au moment de son authentification sur le serveur OpenlD, la sécurité de l'ensemble est compromise.

En délégant la gestion de l'authentification des utilisateurs à des serveurs OpenlD dédiés, les fournisseurs de service n'ont aucune contrainte architecturale quant à la prise en compte de l'authentification mutuelle SSL/TLS réalisée par le composant sécurisé. De la même manière, un serveur d'identités compatible OpenlD peut proposer un service de très haute sécurité à des utilisateurs souhaitant s'affranchir du problème des multiples comptes à base de login / mot de passe. Il suffit que le serveur soit configuré de manière compatible avec le logiciel Agent Utilisateur (User Agent) assurant l'interface avec la pile SSL/TLS du composant sécurisé, pour que les utilisateurs puissent utiliser ce type d'authentification avec tout fournisseur de services compatible OpenlD.

Le scénario de l'authentification d'un utilisateur est alors le suivant: l'utilisateur, préalablement enregistré (à l'aide de son composant sécurisé muni de la pile SSL) sur le serveur d'identités OpenlD décrit dans les sections précédentes, souhaite s'authentifier auprès d'un fournisseur de services compatible OpenlD. Pour cela, il saisit l'identifiant OpenlD de l'une des identités qu'il a générées, et avec laquelle il souhaite s'authentifier. Le fournisseur de services et le serveur d'identités échangent alors leur secret partagé, puis l'utilisateur est redirigé sur l'interface d'authentification du serveur d'identités. Cette interface ne propose en aucun cas une méthode à base de mot de passe. 1 o Elle propose un mécanisme simple, tel un geste volontaire (par exemple une pression sur un bouton) réalisant l'authentification à base du composant sécurisé. Cette interface peut être également inexistante puisque l'utilisateur n'a aucune donnée à saisir. Il est donc possible d'exécuter simplement une redirection afin de réaliser l'authentification mutuelle SSL/TLS. Une fois 15 l'authentification réussie, les données relatives au résultat de l'authentification sont signées par le secret partagé, et plusieurs informations personnelles liées à l'identité de l'utilisateur sont envoyées au fournisseur de services, en accord avec la politique de confidentialité mise en place par ce dernier. Le serveur du fournisseur de services vérifie alors la validité de l'authentification grâce au 20 secret partagé, puis gère de lui-même la phase d'autorisation d'accès de l'utilisateur au service. Notamment, comme dans les cas d'authentification classiques, il vérifie si l'utilisateur possède déjà un compte, et dans ce cas, il prend en compte les droits possédés par l'utilisateur sur ce serveur.

25 Nous avons souligné ci-dessus les faiblesses de l'architecture OpenlD relativement aux deux points suivants: - Utilisation d'un couple identifiant (login) / mot de passe pour l'authentification - Mise en oeuvre standard d'une session SSL/TLS pour la protection des 30 informations échangées entre l'utilisateur et le serveur d'authentification OpenlD. Puisqu'il est difficile pour un humain de reconnaitre un «bon» certificat X509 de serveur, il y a risque de phishing.

La présente invention, décrite ci-dessus, permet une authentification forte basée sur une mutuelle authentification entre un composant (typiquement microcontrôleur) sécurisé et le serveur d'authentification. Le risque de vol de mot de passe disparait et le phishing est rendu difficile grâce à la vérification du certificat du serveur par le composant (typiquement microcontrôleur) sécurisé.

D'autre part, le jeton OpenlD produit au terme d'une procédure d'authentification réussie est également protégé par la session SSL/TLS établie entre le composant (typiquement microcontrôleur) sécurisé et le serveur OpenlD.

La délégation de la gestion de la procédure d'authentification à un composant (typiquement microcontrôleur) sécurisé crée un nouveau problème de sécurité lié à l'éventuelle perte ou vol de ce dispositif. Les mécanismes explicités ci-dessus permettent, en séparant l'identité du composant qui est unique et celle définie par l'utilisateur, la gestion d'une procédure de révocation du composant sécurisé, ainsi qu'une procédure de remise en service des identités précédemment générées sur un nouveau composant.

L'invention est décrite dans ce qui précède à titre d'exemple. Il est entendu que l'homme du métier est à même de réaliser différentes variantes de l'invention sans pour autant sortir du cadre du brevet.

Claims (9)

1. REVENDICATIONS1. Plateforme d'authentification comportant : - un serveur d'identité, - un serveur d'authentification, - un terminal informatique adapté à exécuter un logiciel, ledit logiciel permettant l'échange de données entre : - un serveur (d'identité ou d'authentification), - un composant sécurisé, - et un navigateur disponible sur un terminal (ordinateur personnel, téléphone mobile) d'un client, ladite plateforme d'authentification étant caractérisée en ce que ledit composant sécurisé (typiquement microcontrôleur sécurisé) exécute de manière autonome le protocole SSL ou TLS, et réalise un protocole Handshake lors de l'ouverture d'une session SSL/TLS entre le terminal du client et le serveur d'identité, ledit composant sécurisé étant fabriqué avec un premier certificat et une clé privée, et en ce qu'elle comporte en outre des moyens pour télécharger à partir du serveur d'identité, un ensemble de données chiffré avec la clé publique présente dans le certificat du composant sécurisé, et signé avec une clé privée d'une autorité de certification reconnue par le composant, en mettant en oeuvre une session SSL/TLS ouverte par le composant sécurisé.
2. 2. Plateforme d'authentification selon la revendication 1, caractérisée en ce que ledit serveur d'identité comporte des moyens pour collecter le certificat dudit composant sécurisé.
3. 3. Plateforme d'authentification selon la revendication 2, caractérisée en ce que ledit serveur d'identité comporte des moyens pour extraire du certificat dudit composant sécurisé sa clé publique.
4. 4. Plateforme d'authentification selon l'une au moins des revendications précédentes, caractérisée en ce que ledit serveur comporte des moyens pour construire un containeur sécurisé comportant : - un entête chiffré avec la clé publique du composant sécurisé ; - un container d'identité chiffré avec une clé symétrique renseignée dans l'entête chiffrée ; et - une signature numérique produite par une clé privée appartenant à un tiers de confiance identifié par la clé publique associée.
5. 5. Plateforme d'authentification selon la revendication 4, caractérisée en ce que ledit composant sécurisé comporte des moyens pour analyser ledit containeur sécurisé. 15
6. 6. Plateforme d'authentification selon la revendication 5, caractérisée en ce que ledit composant sécurisé comporte des moyens pour : - vérifier ladite signature avec une clé publique du tiers de confiance, stockée dans le composant sécurisé ; - déchiffrer l'entête avec la clé privée dudit composant 20 sécurisé ; et - décrypter le containeur sécurisé chiffré.
7. 7. Plateforme d'authentification selon la revendication 6, caractérisée en ce que ledit composant sécurisé comporte en outre des moyens pour interpréter des informations contenues dans le containeur sécurisé décrypté.
8. 8. Plateforme d'authentification selon la revendication 7, caractérisée en ce que lesdites informations comprennent l'identité SSL en clair.
9. 9. Plateforme d'authentification comportant : - un serveur d'identité, - un serveur d'authentification, 10 25 30- un terminal informatique adapté à exécuter un logiciel, ledit logiciel permettant l'échange de données entre : - un serveur (d'identité ou d'authentification), - un composant sécurisé, - et un navigateur disponible sur un terminal (ordinateur personnel, téléphone mobile) d'un client, ladite plateforme d'authentification étant caractérisée en ce que ledit composant sécurisé (typiquement microcontrôleur sécurisé) exécute de manière autonome le protocole SSL ou TLS, et réalise un protocole Handshake lors de l'ouverture d'une session SSL/TLS entre le terminal du client et le serveur d'authentification, ledit composant sécurisé étant fabriqué avec un premier certificat et une clé privée, et en ce qu'elle comporte en outre des moyens pour télécharger à partir du serveur d'authentification, un ensemble de données chiffré avec la clé publique présente dans le certificat du composant sécurisé et signé avec une clé privée d'une autorité de certification reconnue par le composant, en mettant en oeuvre une session SSL/TLS ouverte par le composant sécurisé.20