FR2975518A1

FR2975518A1 - METHOD FOR SECURING AN AUTHENTICATION ARCHITECTURE, MATERIAL DEVICES AND CORRESPONDING SOFTWARE

Info

Publication number: FR2975518A1
Application number: FR1254381A
Authority: FR
Inventors: Michel Betirac
Original assignee: ETHERTRUST
Current assignee: ETHERTRUST
Priority date: 2011-05-16
Filing date: 2012-05-14
Publication date: 2012-11-23
Anticipated expiration: 2032-05-14
Also published as: EP2710779A1; FR2975518B1; FR2975551A1; FR2975551B1; WO2012156365A1

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.The present invention relates to a method of securing an authentication architecture and the hardware and software devices for its implementation. The method comprises a phase of creating an identity by an identity server, and a phase of using this identity with an authentication server. According to the invention these operations are secured by a secure component (typically a secure microcontroller). Software, called User Agent, running on the user's terminal, allows data to be exchanged between the three entities: web browser, server and secure component. An Internet user associated with a browser is authenticated by mutual authentication performed between a secure component (typically secure microcontroller) and a WEB server.

Description

PROCEDE DE SECURISATION D'UNE ARCHITECTURE D'AUTHENTIFICATION, DISPOSITIFS MATERIELS ET LOGICIELS CORRESPONDANTS METHOD FOR SECURING AN AUTHENTICATION ARCHITECTURE, MATERIAL DEVICES AND CORRESPONDING SOFTWARE

Domaine de l'invention Field of the invention

La présente invention se rapporte au domaine des Technologies de l'Information et de la Communication. The present invention relates to the field of Information and Communication Technologies.

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. The present invention relates more particularly to a method of securing an authentication architecture, to hardware devices and corresponding software.

15 Etat de la technique 15 State of the art

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. Internet user authentication is a fundamental aspect of the security of digital services available on the Internet such as electronic commerce (eCommerce) or the connection to cloud computing resources.

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. In the current state of the art, the identity of a user is generally a couple of data identifier (login) / password, sometimes reinforced using a device named One Time Password (OTP) in the Anglo-Saxon terminology.

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. The widespread use of passwords for accessing internet services is subject to so-called phishing attacks, the purpose of which is to obtain this information by faithfully reproducing the appearance of a WEB site, in particular the form used. for the information of the couple login (login) password. Another constraint for the user is the definition and storage of multiple passwords. Single Sign On (SSO) technologies or identity federations are designed to reduce the number of identifiers required by Internet services. However, it is clear that the existence of a single password for access to multiple digital resources increases the risk of hacking via malicious software (Trojans) or phishing processes.

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. Single Sign On Platform OpenlD is an open standard, described for example by http://openid.net, which defines an effective solution to the problem of single sign-on. It consists of a decentralized authentication, delegated to entities named OpenlD Servers and which does not depend on the service provider on which the user wants to authenticate. The OpenlD infrastructure is thus based on the following three elements, illustrated by Figure 1: the user (101), the service provider (102), and the OpenlD server itself (103). Authentication methods are multiple and depend on OpenlD servers. They are based on login / password pairs, or on more robust methods involving for example the use of smart cards or biometrics.

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. The first step of the OpenlD architecture involves registering a user with an OpenlD server. Once the account is created, it receives an OpenlD identifier specific to this account in the form of an XRI (eXtensible Resource Identifier), in which appears the address of the OpenlD server. According to the current state of the art this operation is protected by an HTTPS session, the authenticity of the server is based on the verification by the user (by the Web browser that he actually uses) the validity of the X509 certificate of the server.

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. At the end of this first step, the three components of the OpenlD platform interact in the following way, illustrated by 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. The user who wants to authenticate with a service provider selects (when it is available) the OpenlD protocol authentication option. He gives his OpenlD ID (arrow 1). The user is redirected (in the HTTP sense, for example using an automatically executed javascript) to the OpenlD server corresponding to this identifier (arrow 3), and authenticates according to the method available on this server (arrow 4). ), which is independent of the service provider. However, the Provider Authentication Policy Extension (PAPE) specifications established in 2008 allow the service provider to require certain authentication methods on the part of the OpenlD servers, subject to which authentication may be denied by the provider of authentication. 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. When authentication is performed (arrow 5), the user is redirected (in the HTTP sense, for example by using a response status 302) to the service provider (arrow 6). The identity of the user is a set of information encapsulated in an HTML form (104) and signed using a symmetric secret (using an HMAC procedure, RFC 2104) shared between the service provider and the authentication server. This set is very similar to the authentication token concept defined by the SAML 20 (Security Assertion Markup Language) standard. The confidentiality of this data is crucial, since the user proves his identity to the service provider through this form; the method described in this invention advantageously guarantees the confidentiality between the terminal of the user and the server OpenlD. The security of the link between the OpenLD server and the service provider resides in the generation of a shared secret between these two entities (arrow 2) during the user authentication request with the service provider (before his request). redirection to the authentication interface of the OpenID server 30). Once authentication is complete, the user is redirected to the service provider with an HTTP header corresponding to the result of this authentication, signed with an HMAC procedure and the shared secret, which establishes a trust relationship between these three. entities, while the service provider and the OpenlD server have a priori no trust.

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

Problèmes de sécurité du standard OpenlD OpenlD standard security issues

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. The ease of use of the OpenlD architecture, from the point of view of the user as well as the service providers, induces real questions as to the security guarantees it offers. These security issues are all the more vital in the context of OpenlD's single sign-on service, where an attacker can gain access to multiple services at once by spoofing a single account.

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. However, the only security guaranteed by OpenlD is that of the validity of the result of the authentication with the OpenlD server, which is transmitted to the service provider signed by the shared secret and the HMAC procedure. The 2008 PAPE specifications leave freedom for the service provider to require strong authentication methods (eg PKI and / or biometrics), but there is no guarantee that a service provider will in place these specifications in order to require strong security. There is also no obligation in the OpenlD specifications to implement these strong methods. In fact, the majority of existing OpenlD servers are limited to providing authentication type identifier / password, that is to say, a very low level of security.

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). Attacks against the usual OpenlD servers can therefore be conducted in an extremely traditional way, either by searching for the user password or by phishing. These considerations show that, as it stands, the OpenlD architecture needs to increase its security guarantees. The use of the SSLITLS protocol could thus be made mandatory for any OpenlD server. This would be a step forward against phishing attacks, but the SSL / TLS protocol is still insufficient to provide this security satisfactorily, because users are used to sites whose certificates are invalid without it being for so many fallacious sites, and are thus quick to neglect the warnings due to improper certificates. In addition, SSL / TLS is unsatisfactory in user authentication because mutual authentication is rarely practiced. Therefore, the simple implementation of SSL / TLS does not eliminate attacks on the passwords of users. These attacks can be extremely easy to achieve depending on the degree of security of the server. A dictionary attack is often effective because users 1o very often choose simple passwords to remember, but other types of attacks, including classic attacks against Web applications (Cross Site Scripting - XSS, for example) , allow to obtain the user's identifiers without having to overload the query server - which is not very discreet and can easily be subject to security countermeasures. In order to fill the potential gaps in the OpenlD architecture, a strong authentication method should be deployed - including avoiding the use of login / password pairs - as well as eliminating any phishing attacks on the Internet. the server. It is therefore a security architecture which maximizes security while respecting the standards of the Internet. Such security involves the use of secure components such as smart cards to store sensitive elements in a secure manner (unlike computer storage that is not secure because of too many lack of physical and logical protection).

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é. In addition, an OpenlD server provides its users with the creation and management of identities that can be used to authenticate with service providers. Therefore, a solution for securing the global architecture must be compatible with this constraint, in particular by storing the identities generated in the secure component.

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é. The following scientific publications are known in the state of the art: "Convergent identity: Seamless OPENID services for 3G dongles using SSL enabled USIM smart cards" by Pascal URIEN (Consumer Communications and Networking Conference - CCNC - 2011 - IEEE - January 9, 2011 ); - "An OpenlD provider based on SSL smart cards" by Pascal URIEN (Consumer Communications & Networking Conference - CCNC - 2010 - IEEE - 9th January 2010); and Pascal URIEN's "TLS-Tandem: a smart card for Web applications" (Consumer Communications and Networking Conference - CCNC - 2009 - IEEE - January 10, 2009) The prior art is also known, by the French patent application No. FR 2,791,159 (BULL CP8), a method of accessing an object using a browser of the "Web" type cooperating with a smart card, and an architecture for implementing the method.

Exposé de l'invention Presentation of the 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. The present invention relates to a phishing-resistant authentication method and its implementation in the context of identity federation, with the non-limiting example of the OpenlD standard. The authentication platform described by the invention comprises four elements.

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. 1- A secure hardware component, commonly a component (typically microcontroller) secure (called "tamper resistant device" or "secure element") that runs a software integrating the TLS / SSL protocol in a secure environment physically and logically.

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é. 2- A software named User Agent that performs the interface (the logical glue) between the Internet browser (Browser) and the component (typically microcontroller) secure. 3- An identity server that generates identities and manages their life cycle. This information is downloaded via the Internet into secure data structures, called container in this document, which can only be decrypted by the secure component (typically a secure microcontroller). 4- An authentication server of the type Single Sign On, for example an OpenlD server, which dialog via the User Agent (User Agent) with the component (typically microcontroller) secure.

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é. To this end, the present invention relates, in its most general sense, to an authentication platform comprising: an identity server, an authentication server, a computer terminal adapted to execute software, said software allowing the exchange of data between: - a server (identity or authentication), - a secure component, - and a browser available on a terminal (personal computer, mobile phone) of a client, 20 said authentication platform being characterized in that said secure component (typically secure microcontroller) autonomously executes the SSL or TLS protocol, and realizes a handshake protocol when opening an SSL / TLS session between the client terminal and the identity server, said secure component being manufactured with a first certificate and a private key, and further comprising means for downloading from the server An identity set, an encrypted data set with the public key present in the secure component certificate, and signed with a private key of a component-recognized CA, implementing an open SSL / TLS session. by the secure component.

Selon un mode de réalisation, ledit serveur d'identité comporte des moyens pour collecter le certificat dudit composant sécurisé. According to one embodiment, said identity server comprises means for collecting the certificate of said secure component.

Avantageusement, ledit serveur d'identité comporte des moyens pour extraire du certificat dudit composant sécurisé sa clé publique. Advantageously, said identity server comprises means for extracting from the certificate of said secure component its public key.

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é. According to one embodiment, said server comprises means for constructing a secure container comprising: an encrypted header with the public key of the secure component; an encrypted identity container with a symmetrical key 1o entered in the encrypted header; and a digital signature produced by a private key belonging to a trusted third party identified by the associated public key. Preferably, said secure component comprises means for analyzing said secure container.

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é. According to one embodiment, said secure component comprises means for: checking said signature with a public key of the trusted third party stored in the secure component; decrypting the header with the private key of said secure component; and - decrypt the encrypted secure container. Advantageously, said secure component further comprises means for interpreting information contained in the decrypted secure container.

De préférence, lesdites informations comprennent l'identité SSL en clair. Preferably, said information comprises the SSL identity in clear.

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é. The present invention also relates to an authentication platform comprising: - an identity server, - an authentication server, - a computer terminal adapted to execute software, said software allowing the exchange of data between: - a server (identity or authentication), - a secure component, - and a browser available on a terminal (personal computer, mobile phone) of a client, said authentication platform being characterized in that said secure component (typically secure microcontroller) autonomously executes the SSL or TLS protocol, and performs a handshake protocol when opening an SSL / TLS session between the client terminal and the authentication server, said secure component being manufactured with a first certificate and a private key, and in that it further comprises means for downloading from the authentication server, a set of data encrypted with the public key present in the secure component certificate and signed with a private key of a certification authority recognized by the component, implementing an SSL / TLS session opened by the secure component.

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 BRIEF DESCRIPTION OF THE DRAWINGS The invention will be better understood by means of the following description, given for purely explanatory purposes, of an embodiment of the invention, with reference to the figures in which: FIG. 1 illustrates the typical structure of an OpenlD authentication platform, which includes the user (101), the service provider (102), and the OpenlD server itself (103). - Figure 2 briefly shows how to open an SSL / TLS session using a secure component. The WEB browser sends a connection opening request to the proxy of the client station (201), which transmits it to the component embedding the SSL / TLS stack (202). The Handshake Hello Client is then generated by the component and then transmitted to the server (203) through the proxy. Once the Lo phase of Handshake is complete the session is transferred to the terminal. - Figure 3 describes the lifecycle of the identity of the secure component. It comprises a manufacturing phase, the emission of the component and its management by its user. - Figure 4 illustrates the structure of an encrypted container of identity. The latter consists of a header encrypted with the public key of the secure component, a section of encrypted identity data using a symmetric key, and an asymmetric signature. - Figure 5 represents the method of securing an authentication platform OpenlD. The latter is implemented thanks to a secure component, typically a secure microcontroller (501), User Agent software (502) running on a terminal (PC, smartphone, etc.), an identity server. (503), and an OpenlD authentication server (504). Figure 6 details the logical structure of a User Agent in the form of a proxy software, including a server socket and a client socket. - Figure 7 illustrates the logical structure of a User Agent in the form of a WEB applet using the packages and classes netscape.javascript.JSObject, Socket, and javax.smartcardio. DETAILED DESCRIPTION OF THE EMBODIMENTS OF THE 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. The present invention provides global security of an authentication architecture such as OpenlD, while ensuring the management of identities.

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). It consists of four entities, described in FIG. 5, a secure component, typically a secure microcontroller (501), a User Agent or User Agent software (502) running on a terminal (PC, smartphone, etc.), a an identity server (503), and an OpenlD authentication server (504).

1 o Le composant sécurisé 1 o The secure component

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. A secure component, typically a secure microcontroller, is a physically and logically secure hardened electronic component, such as the current ST22 or ST23 references of STMicroelectronics, Smart MX (PN532), ..) of the company NXP, SLE66 or SLE68 of the company Infineon. In the context of this invention these components (typically microcontrollers) embody an implementation of the SSL / TLS protocol, usually called SSL / TLS stack or "stack" in Anglo-Saxon terminology. It should be noted that the term component (typically microcontroller) secure is used in this document in a broad sense, representative of any component, integrated circuit, for performing the processing of elementary operations in a given sequence. This therefore includes FPGA type 25 components, microprocessors or DSPs ... Without this list being 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). The secure (typically microcontroller) components typically use a command format defined by the ISO7816 standard, represented by the 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. Secure Sockets Layer (SSL), is a protocol for securing exchanges on the Internet, developed by Netscape with two major versions SSL version 2 and SSL version 3. Since 2001 it is standardized by the IETF (www.ietf.org) under the acronym TLS (Transport Layer Security) by RFC 2246, RFC 4346, RFC 5246, RFC 4347. In this document the terms SSL and TLS refer to these different 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. This implementation is carried out so that the size of the code (of the order of a few tens of kiloOctets) can fit in the non-volatile memory of the smaller components. It can be integrated into any type of component (typically microcontroller) secure, whether it is a SIM card, a JavaCard, an NFC component, a SmartMX processor. Unlike 1 o data stored on a conventional computer hard drive type or FLASH memory, components (typically microcontroller) secure benefits from physical and logical countermeasures that make it very difficult to read or modify unauthorized data.

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é. The secure component acts as an SSL / TLS client, logically integrated with the client terminal in order to unload the terminal from the realization of the SSL / TLS handshake. Thus, when a user wishes to connect via his browser to a WEB server in SSL / TLS (that is to say HTTPS), the establishment of the session (Handshake protocol) is entirely carried out by the secure component 20 .

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. The SSL / TLS stack is implemented on the form of a state machine, both in "full" mode and in "resume" mode (also called "abbreviated"), in which all the cryptographic calculations of the protocol 25 Handshake of SSL / TLS are performed in the component. These calculations include symmetric asymmetrical cryptography (RSA, Diffie-Hellman, Elliptic Curves) (RC4, DES, 3xDES, AES ...) and hash functions (SHA1, SHA256, MD5, HMAC ...). The "Master Secret" of the SSL / TLS session is thus directly calculated and stored in the secure component. Moreover, the SSL / TLS packets can be advantageously encapsulated via the EAP protocol, according to the specifications of the EAP-TLS standard (RFC 2716, RFC 5216), thus ensuring a transport of the packets in datagram mode and thus conferring increased security .

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. The EAP-TLS standard also requires mutual authentication between client and server (the client authenticates with the Verify message). The X509 client certificate is stored in an Identity Container (detailed in section 3-C) on the secure component, as well as its private key.

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. Once the Handshake phase is complete, the values of the ephemeral keys contained in the "KeyBlocks" and derived from the Master Secret may or may not be exported to the client terminal, so that the symmetric encryption of the SSL / TLS session can be realized either by the secure component, ie the terminal according to the needs of the application. This choice does not modify the security process of the OpenlD platform described in this 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. An SSL / TLS stack advantageously embedded in a secure component makes it possible, by the nature of the latter, to prevent the SSL / TLS software implementation flaws usually present on the client terminals, and thus avoids a potential modification of the security code. the latter or the recovery of sensitive data by a third party, or malicious software (malware) such as a Trojan.

L'Agent Utilisateur (User Agent) The 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, ...). The User Agent software performs the "logical glue" (logical interface) between a WEB server (identity server or OpenID server) and the secure component (typically microcontroller). It is executed in a computer terminal such as personal computer, tablet or smartphone, under the supervision of various operating systems (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. It carries out the communication between the client terminal, equipped with a web browser and the secure component, but also the link between the secure component (typically microcontroller) and the web server during an SSL / TLS connection.

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). The User Agent software is compatible with all kinds of physical and logical interfaces to the secure component, including USB bus, PC / SC, AT-CSIM, serial port, contactless: NFC, BLUETOOTH, Wi-Fi, without this list is restrictive. Thus, the components (typically microcontrollers) secure can communicate transparently to a WEB server to establish an SSLITLS session. The source code of the SSL / TLS stack is suitable for each type of interface, for example using variable sizes of EAP packets. The User Agent software can be realized by means of a proxy software (based on the Socket library for TCP / IP), or in other forms such as a Java APPLET downloaded and executed in an Internet browser. In the remainder of this document, the architectures corresponding to these two examples will be detailed, without these examples being a limitation for the implementation of the User Agent software.

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). Figure 6 illustrates the logical structure of a "proxy" User Agent. The User Agent (602) manages a server socket (604) that interfaces with the WEB browser (601), and a client socket (605) that establishes a TCP connection with a remote server (603). It also manages a communication port with the component (typically microcontroller) secure (606) which can thus exchange data with the browser (601) and the server (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. Figure 7 shows the logical structure of a Java APPLET User Agent. The web browser (701) downloads an HTML page containing a signed APPLET (702) (for example with the jarsigner tool) and stored on a server (703). This APPLET establishes TCP connections to the server (703) using a client socket provided by the JAVA Socket class; it can also exchange information with the secure component (707) (typically microcontroller) by means of the class javax.smartcardio (706) available from version 1.6 of the JAVA language. The netscape.javascript.JSObject class supported by most WEB browsers allows to run a JavaScript associated with the HTML page loaded by the browser (using the netscape.javascript.JSObject.eval method), and especially HTTP redirection after inserting a 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 The User Agent software converts particular HTTP requests into a suite of APDUs, defined by the ISO 7816 standard, for example the URL

http://127.0.0.1:8080/-apdu?=cmd1&=cmd2...&=cmdn 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. 1 o is interpreted by a User Agent as a succession of (n) APDUs commands (cmdi, cmd2, cmdn) transmitted to the component (typically microcontroller) secure. Responses to these commands are returned in HTML or XML format.

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 : In order to perform the SSL / TLS connection openings via the User Agent (in this case "proxy"), the URL executed by a WEB browser has a specific format, of the 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. http://127.0.0.1:8080/-url=serveur.com 20 Thus, as shown in Figure 2, the WEB browser sends a request to open a connection to the "User Agent" (in this case "proxy") the client station (201), which transmits it (arrow 1) to the component embedding the SSL / TLS stack (202). The Handshake Hello Client is then generated by the component and then transmitted to the server (203) through the proxy. The continuation of the handshake is then carried out directly between the secure component and the server, via the "User Agent" (in this case "proxy") (arrow 2), which does not take into account the retransmissions of the SSL / TLS packets to the "User Agent" (in this case "proxy") that has only an intermediary role. In the case where the temporary session keys are exported on the client station (arrow 3), the component is no longer involved in the continuation of the SSL / TLS session, namely the encrypted data exchange phase (arrow 4). ) between client and server. Otherwise, it is the latter that performs the cryptographic calculations necessary for the exchange of encrypted data.

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". One of the possible alternatives to the use of a proxy, which makes it possible to advantageously manage session cookies during authentication on a WEB server, is a Java Applet delivering the same services as the proxy. It is then the Applet that interfaces with the secure component and the browser, thanks for example to the class netscape.javascript.JSObject available on WEB browsers, which allows 1 o to run javacripts embedded on a page HTML, and can be instantiated according to the method called "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». The secure component embedding the SSL / TLS stack also stores an identity, which may be of the "client" or "server" type, that is, realizing the client-side or server-side SSL / TLS protocol. In the case of authentication on a standard WEB server, this identity will be of the "client" type, but other applications may require a "server" type identity, particularly in the context of the Internet of Things (Internet Of Things). Things) and applications for example M2M (Machine to Machine). In the remainder of this document, we will assume that the user identity is of the "client" type.

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. The format of this identity (also called Identity Container in this document) is described below. This identity contains, among other elements, the user's certificate and the associated private key. This identity can be generated by tools such as OpenSSL, and then loaded into the secure component through dedicated or standard APDUs (such as non-volatile memory write command). This loading can be done either locally, via software managing the exchange of data with the component, or remotely via a WEB interface with a dedicated server. The identity is produced at the request of the user. The user must simply enter a username (such as his name or a pseudonym) to generate an Identity Container that contains a certificate that, for example, the Common Name attribute matches the name. he seized before.

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: The identity loading WEB interface is built on the joint use of the User Agent (proxy or WEB applet) and AJAX (Asynchronous Javascript and XML) technology, in particular the implementation of the XMLHttpRequest API defined by the W3C consortium (http://www.w3.org). Indeed, once the identity generated on the WEB server at the request of the user, the corresponding container is inserted in a page 1 o provided with AJAX features. The latter make it possible to carry out a transparent loading of the identity in the component. The link between the component and the server is established using the User Agent, which is the target of the AJAX request launched from the WEB page. The User Agent transmits the request, that is, the APDUs, to the component, and analyzes the response of the component. If none of the returned statuses report an error in APDU processing, the User Agent re-emits a 200 status HTTP response, so that the AJAX interface can receive an answer and process it. as a result (for example, by displaying a message of successful loading of the identity). The AJAX interface issuing a request directly to the proxy (via the XMLHttpRequest object), that is to say to the local host 127.0.0.1, the policy of the same origin requires that the WEB page from which this query belongs to the same domain. In the present case, this means that the user will have to have authenticated beforehand so that the page containing the AJAX interface has a URL of the type:

http://127.0.0.1:8080/-url=server.com/download_identity.html. 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é Depending on the cases considered, it may be possible to store one or more identities on a component. In the case where a single identity is stored, it can be updated (that is, deleted and then rewritten) by that interface, using an appropriate APDU for this purpose. In the case of storing multiple identities, several Identity Containers are juxtaposed in the component by dynamically generating an appropriate write address in the component during the generation of the identity. In this case, the choice of the location of the identity to be loaded in the component can be proposed to the user during his request for identity generation. The identity server

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é). An SSL / TLS identity (also called Identity Container), as stored in the component, has at least the following fields, 1 o preceded each time it is necessary to one or two bytes giving their length: - the type of the identity (client or server), - the name associated with the identity, - the EAP-TLS identity (necessary in case of an EAP.Identity-Request request), - and a set of keys needed to establish an SSL / TLS session (for example the RSA private key, and the certificate associated with the identity).

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é. Furthermore, the public keys of the certification authorities accepted by the component must have been previously stored in the embedded SSL / TLS protocol code.

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é. The root identity of the component is a set of parameters inserted in the production phase of the component, which comprises the following elements: The certificate of the certification authority that generates the certificates accepted by the component. - The asymmetric private key associated with the component (RSA, ECC) - The certificate associated with the public asymmetric key of the component, issued by the certification authority, and which integrates (for example into the DN attribute) a unique identifier such as for example serial number or telephone number.5 The SSL / TLS standard uses certificates in X509 format. However, multiple formats may be available in the component without having any influence on the method described in this document. In the context of an identity server, the main feature is to be able to generate and store several identities for a single user, that is to say for a single secure component.

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. 1 o The term user refers to a human user able to interact with the User Agent software, or a computer system exchanging data through a communication interface (ISO7816, USB, I2C, ISO 14443, NFC ...) with the software User Agent stored in the component.

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. To this end, it is necessary to link the generation of the identities to the component held by the user, as described in FIG. 3. For this, after the component is made in the factory (step 301), an SSL / TLS "root" is stored in the component, associated with a unique identifier (serial number), as well as the corresponding private key (step 302). When the user receives his component (step 303), he must register with the identity server using his component and his "root" certificate. During this step, it must enter personal information that will be associated with its component, including its "root" identity (step 304). Subsequently, the user will be able to generate identities on this server, and store them freely in his component, with the exception that he will never be able to erase or rewrite the "root" identity (step 305). It is the latter which contains the public key rendering the component unique, and it is through this public key that the server is able to associate the identities generated to the component to which it is linked. Whenever the user wishes to manage his identities (creation or destruction, modification of information related to identities), he must first authenticate himself on the identity server using his "root" identity. However, it can subsequently, if it wishes, select one of the identities5 present in its component in order to use it with a WEB server to perform an authentication.

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. When the user wishes to create an identity, he must enter the name given to this identity, and may for example enter a number that will determine the storage address of the identity in the non-volatile memory of the component. Identities in the component must also be listed on the Identity Server database to ensure consistency of user actions. Similarly, when an identity on the component is removed or rewritten, the server must be updated accordingly to be synchronized with the data on the user's component.

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. Finally, in the case where the user has lost its component, it must report this fact to the administrators of the identity server (in case the component has reached the end of its life, this will be automatically detected by the server) , so that all X509 certificates issued when generating the SSL / TLS identities of this user are revoked. The public key of the "root" identity of the component is then placed in a blacklist (step 306). If a connection attempt was made from this identity, it would be denied by the identity server. However, the user can keep his old account on the identity server. Indeed, when he has in his possession a new component, with a new identity "root", he will have to prove his identity to administrators of the server, using the personal information entered when it was registered on the server. If these are valid, the new public key of the component may be linked to its old account on this identity server.

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é. Identity management security loaded from the WEB server to the secure component relies on the use of encryption that makes it impossible to illegally load the identity into the component. The implementation of some mechanisms will be designed to overcome the following possible negative effects: the architecture described above is subject to several potential security flaws related to the generation of an identity container that is inserted into a page WEB to be loaded into the component via an AJAX interface. A user can therefore observe the format of the container and possibly use the same write APDUs in another component, in order to load itself an identity without having declared this action to the server. In addition, it would be possible for the user to launch write commands in nonvolatile memory himself in order to enter himself information component. Finally, the Identity Container contains the private key of the generated identity, which is much too sensitive information to appear in a clear WEB page, even if it is positioned in a hidden field.

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. In order to remedy these flaws, an encrypted container is generated by the identity server, as shown in 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. The term "clear container" denotes a set of data interpreted by the secure component. In Figure 401 this set named "SSL identity" contains all the information necessary to establish an SSL / TLS session with mutual authentication, ie an X509 certificate and the associated private key, the certificate of the authority certification, as well as various parameters including an alias of the SSL identity.

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. The plaintext container is encrypted by a symmetric cryptographic algorithm, for example AES, using a key (named K in FIG. 401) whose value is set randomly. Cipher block (cipher block) encryption uses data lengths that are multiple of an integer (for example 16 bytes for AES), the encrypted container therefore has a length that may be greater than that of the plaintext container, according to a technique based on so-called padding bytes added as a suffix.

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é. The encryption key (K) is inserted into a header (402), which also contains several information such as the nature of the encryption algorithm used, the length of the clear container, and the signature algorithm used.

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. When establishing the SSL / TLS session between the secure component and the server, the server has collected the certificate of the secure component that contains the public key Kpub. This key makes it possible to perform the asymmetric encryption of the header 402 (for example via the RSA algorithm) according to standardized methods such as PKCS # 1. In the current state of the art, only the knowledge of the private key Kpriv (stored in the secure component) can decrypt the encrypted header 402. However, the public nature of the Kpub key allows any (possibly hostile) entity to generate encrypted headers and containers. For this reason, all the data resulting from the concatenation of the encrypted header and the encrypted container is signed (for example with a standardized method such as PKCS # 1) by means of a private key associated with an encrypted header. trusted entity recognized by the secure component. This relationship is based on the fact that the secure component knows the public key of the trusted entity, and that it is therefore able to verify this digital signature.

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. In summary, the delivery of a secure container relies on the following elements: Mutual authentication is performed using an SSL / TLS session between a secure component and a server. In particular the server has collected the certificate of the secure component. The server extracts from the certificate of the secure component its public key The server (or another entity) builds a secure container comprising three subsets 1) An encrypted header with the public key of the secure component 2) An identity container encrypted with a symmetric key entered in the encrypted header. 3) A digital signature produced by a private key belonging to a trusted third party identified by the associated public key.

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é. The secure container is analyzed by the secure component according to the following scenario: 1) The signature is verified with the public key of the trusted third party, stored in the secure component. 2) If the previous operation is successful, the header is decrypted with the private key of the secure component. The nature of the symmetric encryption algorithm and its key are then determined as well as the size of the container in clear. 3) The encrypted container is decrypted, which allows 1 o to obtain the information (SSL identity in clear). This information is then interpreted by the secure component.

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é. The Clear Container (401) is first encrypted by the server using a key of a symmetric algorithm (eg AES). This key is placed in a fixed length header (402) which also contains a plurality of information related to the generated identity (such as the name given to the identity, the location of the identity in the component). , as well as the Unix generation time of the Container. This header is asymmetrically encrypted using the public key of the component (the "root" public key), retrieved during the connection to the identity server made by the user, and essential to the progress of the the identity creation stage.

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. Finally, the encrypted header concatenated with the identity container encrypted by the symmetric key is digitally signed with the private key of the identity server 25 which here plays the role of the certification authority (CA), for example in PKCS # 1 format. The set then constitutes the encrypted container (403) ready to be sent to the component with appropriate write APDUs. Indeed, these APDUs write to a virtual address, which means that the contents of the encrypted container is not stored directly in the non-volatile memory of the secure component. It must first be verified by the component. For this, it first checks the digital signature, then, if it is correct, it decrypts the header of the Container with its private key "root". It recovers from this header the symmetric key previously used to encrypt the SSL / TLS Identity that was originally clear, and decrypts it. If all the operations proceeded without error, the Container in clear is then written in nonvolatile memory at the location selected by the user (location stored in particular in the header submitted to the component). On the other hand, if an error occurs in one of the previous steps, an error status is returned to the browser via the User Agent (typically the proxy), and the Identity Container is rejected without being written in non-volatile memory.

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. The OpenlD Authentication Server The implementation of the platform described in the previous sections can be applied to identity federation architectures based on the generation and transport of secure tokens, in the manner of OpenlD (described below). -above). Indeed, OpenlD works on the principle of a secret exchange between the service provider and the OpenlD server, as mentioned above. This secret is then used to prove that the user has successfully performed an authentication on the OpenlD server mentioned in his OpenlD identifier. However, if it turns out that the user was able to cheat when it was authenticated on the OpenlD server, the security of the set is compromised.

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. By delegating the management of user authentication to dedicated OpenlD servers, service providers have no architectural constraint as to whether SSL / TLS mutual authentication is performed by the secure component. In the same way, an OpenlD-compatible identity server can offer a very high security service to users wishing to overcome the problem of multiple accounts based on login / password. The server only needs to be configured in a way that is compatible with the User Agent software that interfaces with the SSL / TLS stack of the secure component, so that users can use this type of authentication with any compatible service provider. 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. The scenario of the authentication of a user is then the following: the user, previously registered (using his secure component with the SSL stack) on the identity server OpenlD described in the previous sections, wishes authenticate with an OpenlD compliant service provider. For this, he enters the OpenlD identifier of one of the identities he generated, and with which he wishes to authenticate. The service provider and the identity server then exchange their shared secret and the user is redirected to the authentication interface of the identity server. This interface does not offer a password-based method. 1 o It proposes a simple mechanism, such as a voluntary gesture (for example a push of a button) carrying out the authentication based on the secure component. This interface may also be non-existent since the user has no data to enter. It is therefore possible to simply perform a redirection to perform SSL / TLS mutual authentication. Once the authentication is successful, the data relating to the result of the authentication is signed by the shared secret, and several personal information related to the identity of the user are sent to the service provider, in accordance with the policy of confidentiality put in place by the latter. The service provider's server then verifies the validity of the authentication using the shared secret and then manages the access authorization phase of the user of the service himself. In particular, as in the case of conventional authentication, it checks whether the user already has an account, and in this case, it takes into account the rights possessed by the user on this server.

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. 25 We have highlighted the weaknesses of the OpenlD architecture above with regard to the following two points: - Use of a login / password pair for authentication - Standard implementation of an SSL / TLS session for the protection of the information exchanged between the user and the OpenlD authentication server. Since it is difficult for a human to recognize a "good" X509 server certificate, there is a risk of 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é. The present invention, described above, allows strong authentication based on a mutual authentication between a secure component (typically microcontroller) and the authentication server. The risk of password theft disappears and phishing is made difficult through the verification of the server certificate by the component (typically microcontroller) secure.

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. On the other hand, the OpenlD token generated after a successful authentication procedure is also protected by the SSL / TLS session established between the secure component (typically microcontroller) and the OpenlD server.

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. The delegation of the management of the authentication procedure to a secure component (typically microcontroller) creates a new security problem related to the possible loss or theft of this device. The mechanisms explained above make it possible, by separating the identity of the component that is unique and that defined by the user, the management of a procedure for revoking the secure component, as well as a procedure for putting the identities previously back into service. generated on a new component.

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. The invention is described in the foregoing by way of example. It is understood that the skilled person is able to realize different variants of the invention without departing from the scope of the patent.

Claims

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é. REVENDICATIONS1. Authentication platform comprising: - an identity server, - an authentication server, - a computer terminal adapted to execute software, said software allowing the exchange of data between: - a server (identity or authentication), - a secure component, - and a browser available on a terminal (personal computer, mobile phone) of a client, said authentication platform being characterized in that said secure component (typically secure microcontroller) executes autonomously the SSL or TLS protocol, and realizes a handshake protocol when opening an SSL / TLS session between the client terminal and the identity server, said secure component being manufactured with a first certificate and a private key, and in that it further comprises means for downloading from the identity server, a set of data encrypted with the public key present in the certificate d u secure component, and signed with a private key of a certification authority recognized by the component, implementing an SSL / TLS session opened by the secure component.

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é. 2. Authentication platform according to claim 1, characterized in that said identity server comprises means for collecting the certificate of said secure component.

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. 3. authentication platform according to claim 2, characterized in that said identity server comprises means for extracting the certificate of said secure component public key.

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. 4. Authentication platform according to at least one of the preceding claims, characterized in that said server comprises means for constructing a secure container comprising: an encrypted header with the public key of the secure component; an encrypted identity container with a symmetric key entered in the encrypted header; and a digital signature produced by a private key belonging to a trusted third party identified by the associated public key.

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 5. Authentication platform according to claim 4, characterized in that said secure component comprises means for analyzing said secure container. 15

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é. 6. Authentication platform according to claim 5, characterized in that said secure component comprises means for: - checking said signature with a public key of the trusted third party, stored in the secure component; decrypting the header with the private key of said secure component; and - decrypt the encrypted secure container.

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é. 7. Authentication platform according to claim 6, characterized in that said secure component further comprises means for interpreting information contained in the decrypted secure container.

8. Plateforme d'authentification selon la revendication 7, caractérisée en ce que lesdites informations comprennent l'identité SSL en clair. 8. Authentication platform according to claim 7, characterized in that said information comprises the SSL identity in clear.

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 9. Authentication platform comprising: an identity server, an authentication server, a computer terminal adapted to execute software, said software allowing the exchange of data between: a server (d); identity or authentication), a secure component, and a browser available on a terminal (personal computer, mobile phone) of a client, said authentication platform being characterized in that said secure component (typically secure microcontroller ) autonomously executes the SSL or TLS protocol, and performs a Handshake protocol when opening an SSL / TLS session between the client terminal and the authentication server, said secure component being manufactured with a first certificate and a private key, and in that it further comprises means for downloading from the authentication server, a set of data encrypted with the public key near in the certificate of the secure and signed component with a private key of a certification authority recognized by the component, implementing an SSL / TLS session opened by the secure component.