WO2012156365A1

WO2012156365A1 - Method for securing an authentication platform, and corresponding hardware and software

Info

Publication number: WO2012156365A1
Application number: PCT/EP2012/058928
Authority: WO
Inventors: Michel Betirac
Original assignee: Ethertrust
Priority date: 2011-05-16
Filing date: 2012-05-14
Publication date: 2012-11-22
Also published as: EP2710779A1; FR2975518B1; FR2975551A1; FR2975551B1; FR2975518A1

Abstract

The present invention relates to a method for securing an authentication platform, and to the hardware and software for implementing same. The method comprises a phase of creation of an identity by an identity server, and a phase of use of said identity with an authentication server. According to the invention, said operations are secured by a secure component (typically a secure microcontroller). Software, called User Agent, which is run on the terminal of the Internet user, makes it possible to exchange data between the three entities of: WEB navigator, server, and secure component. An Internet user associated with a navigator is authenticated by a mutual authentication carried out between a secure component (typically a secure microcontroller) and a WEB server.

Description

METHOD FOR SECURING AN AUTHENTICATION PLATFORM, CORRESPONDING DEVICES AND SOFTWARE

Field of the invention

The present invention relates to the field of Information and Communication Technologies.

The present invention relates more particularly to a method of securing an authentication architecture, to hardware devices and corresponding software.

State of the art

Web user authentication is a fundamental aspect of the security of digital services available on the Internet such as electronic commerce (eCommerce) or connection to cloud-based resources.

In the current state of the art, the identity of a user is usually a couple of data identifier (login) / password, sometimes reinforced with a device named One Time Password (OTP) in Anglo-Saxon terminology.

The widespread use of passwords to access 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 to the couple information 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.

Single Sign On Platform

OpenID 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 OpenID Servers and which does not depend on the service provider on which the user wishes to authenticate. The OpenID infrastructure is thus based on the following three elements, illustrated by Figure 1: the user (101), the service provider (102), and the OpenID server itself (103). Authentication methods are multiple and depend on OpenID servers. They are based on login / password pairs, or on more robust methods involving for example the use of smart cards or biometrics.

The first step of the OpenID architecture involves registering a user with an OpenID server. Once the account is created, it receives an OpenID identifier specific to this account in the form of an Extensible Resource Identifier (XRI), in which appears the address of the OpenID 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.

At the end of this first step, the three components of the OpenID platform interact in the following way, illustrated by Figure 1. The user who wants to authenticate with a service provider selects (when it is available) the OpenID protocol authentication option. He gives his OpenID identifier (arrow 1). The user is redirected (in the HTTP sense, for example using an automatically executed javascript) to the OpenID 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 OpenID servers, subject to which authentication may be denied by the service provider.

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 Security Assertion Markup Language (SAML) 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 user's terminal and the OpenID server.

The security of the link between the OpenID server and the service provider resides in the generation of a shared secret between these two entities (arrow 2) during the request for authentication of the user with the service provider (before his redirection to the authentication interface of the OpenID server). 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 supplier services and the OpenID server have a priori no trust.

The OpenID architecture also performs single sign-on.

OpenID security issues

The ease of use of the OpenID architecture, from the point of view of the user as well as the service providers, leads to real questions as to the security guarantees it offers. These security issues are all the more vital in the context of OpenID's unique authentication service, where an attacker can gain access to multiple services at once by spoofing a single account.

However, the only security guaranteed by OpenID is that of the validity of the result of the authentication with the OpenID 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 requirement in the OpenID specifications to implement these strong methods. In fact, the majority of existing OpenID servers are limited to providing authentication type identifier / password, that is to say, a very low level of security.

Attacks against the usual OpenID servers can therefore be carried out in an extremely traditional way, either by searching for the user password or by phishing. These considerations show that, as it stands, the OpenID architecture needs to increase its security guarantees. The use of SSL / TLS could be made mandatory for any OpenID server. This would be a step forward against phishing attacks, but the SSL / TLS protocol is still insufficient to ensure this security of This is satisfactory because users are accustomed to sites with invalid certificates without being misleading sites, and are thus quick to overlook warnings of 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 very often choose easy-to-remember passwords, but other types of attacks, such as traditional Web application attacks (Cross Site Scripting - XSS, for example), allow to obtain user credentials 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 of the OpenID architecture, it is therefore necessary to deploy a strong authentication method - consisting in particular of avoiding the use of identifier / password pairs - as well as to eliminate any phishing attack on the Internet. server. It is therefore a security architecture that 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).

In addition, an OpenID 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.

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 - 201 1 - IEEE - 9 January 201 1); · "An OpenID 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 also knows, by the French patent application No. FR 2 791 159 (BULL CP8), a method of accessing an object using a browser of "Web" type cooperating with a card. chip, and an architecture for the implementation of the method.

Presentation of the invention

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 OpenID standard. The authentication platform described by the invention comprises four elements.

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- A software named User Agent that performs the interface (the logical glue) between the 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 OpenID server, which dialog via the User Agent (User Agent) with the component (typically microcontroller) secure. For this purpose, 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 enabling 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 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 of the 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.

According to one embodiment, said identity server comprises means for collecting the certificate of said secure component. Advantageously, said identity server comprises means for extracting from the certificate of said secure component its public key.

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 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.

Preferably, said secure component comprises means for analyzing said secure container.

According to one embodiment, said secure component comprises means for:

• verify said signature with a public key of the trusted third party, stored in the secure component;

• decrypt 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.

Preferably, said information comprises the SSL identity in clear.

The present invention also relates to an authentication platform comprising: - an identity server,

an authentication server,

- a server (identity or authentication),

- a secure component,

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 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 certificate of the secure component and signed with a private key of a recognized certification authority by the component, implementing an SSL / TLS session opened by the secure component.

Brief description of the drawings

The invention will be better understood by means of the description, given below purely for explanatory purposes, of one embodiment of the invention, with reference to the figures in which: Figure 1 illustrates the typical structure of an OpenID authentication platform, which includes the user (101), the service provider (102), and the OpenID 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 handshake phase 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 asymmetrical signature.

Figure 5 shows the method of securing an OpenID authentication platform. The latter is implemented thanks to a secure component, typically a secure microcontroller (501), a User Agent software, a User Agent (502) running on a terminal (PC, smartphone, etc.), an identity server ( 503), and an OpenID 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 netscape.javascript.JSObject, Socket, and javax.smartcardio packages and classes. DETAILED DESCRIPTION OF THE EMBODIMENTS OF THE INVENTION

The present invention provides a global security of an authentication architecture such as OpenID, while ensuring the management of identities. 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 identity server (503), and an authentication server OpenID (504). The secure component

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 NXP, SLE66 or SLE68 of 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 includes components such as FPGA, microprocessors or DSP ... Without this list is exhaustive.

The components (typically microcontroller) secure generally use a command format defined by ISO7816, represented by the acronym APDU (Application Protocol Data Unit).

Secure Sockets Layer (SSL), is a protocol for securing Internet exchanges, 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. 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 data stored on a conventional hard drive or FLASH memory medium, secure (typically microcontroller) components benefit from physical and logical countermeasures that make it very difficult to read or modify unauthorized data. 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 (the Handshake protocol) is performed entirely by the secure component.

The SSL / TLS stack is implemented on the form of a state machine, both in "full" mode and in "summarize" mode (also called "abbreviated"), in which all SSL Handshake protocol cryptographic calculations / 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. In addition, 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 transport of packets in datagram mode and thus conferring increased security. 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.

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 OpenID platform described in this document.

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.

The User Agent

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, ...). 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. 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 be limiting. Thus, the components (typically microcontrollers) secure can transparently communicate to a WEB server to establish an SSL / TLS 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.

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).

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 in particular to perform an HTTP redirection after inserting a cookie.

The User Agent software converts particular HTTP requests into a series of APDUs, defined by the ISO 7816 standard, for example the URL http://127.0.0.1: 8080 / ~ apdu? = Cmdi & = cmd ₂ ... & = cmd _n is interpreted by a User Agent as a succession of (n) APDUs commands (cmdi, cmd ₂ , cmd _n ) transmitted to the secure component (typically microcontroller). Responses to these commands are returned in HTML or XML format. In order to perform SSL / TLS login openings through 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 = server.com

Thus, as shown in FIG. 2, the WEB browser sends a connection opening request to the "User Agent" (in this case "proxy") of the client station (201), which transmits it (arrow 1) to the embedding component. 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 no longer intervenes in the continuation of the SSL / TLS session, namely the encrypted data exchange phase (arrow 4). enter client and server. Otherwise, it is the latter that performs the cryptographic calculations necessary for the exchange of encrypted data.

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 to run javacripts embedded on an HTML page, and can be instantiated according to the method called "Java Reflection".

The secure component embedding the SSL / TLS stack also stores an identity, which can be of the "client" or "server" type, that is to say realizing the SSL / TLS protocol on the client or server side. 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.

The format of this identity (also called Identity Container in this document) is described below. This identity contains, among other things, 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 for example, the Common Name attribute matches the name that he entered earlier.

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 into a page 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 sends 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 the WEB page from which this request originates belongs to the same domain. In this case, this means that the user will have to authenticate 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. 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 the storage of several 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

An SSL / TLS identity (also called Identity Container), as stored in the component, has at least the following fields preceded whenever necessary by one or two bytes giving their length:

- the type of identity (client or server),

- The name associated with the identity,

- The EAP-TLS Identity (necessary in case of EAP.Identity-Request),

- and a series of keys necessary to establish an SSL / TLS session (for example the RSA private key, and the certificate associated with the identity). In addition, the public keys of the certification authorities accepted by the component must have been previously stored in the embedded SSL / TLS protocol code.

The root identity of the component is a set of parameters inserted into the component production phase, which includes the following elements:

- The certificate authority certificate 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 in the DN attribute) a unique identifier such as, for example, serial number or telephone number. 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. The term user refers to a human user capable of interacting with the User Agent software, or a computer system exchanging data through a communication interface (ISO7816, USB, I2C, ISO 14443, NFC.) With the User Agent software stored in the component. To this end, it is necessary to link the generation of identities to the component held by the user, as described in Figure 3. For this, after the completion of the component at the factory (step 301), an SSL / TLS identity "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 can never erase or rewrite the identity "root" (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, he may subsequently, if he wishes, select one of the identities present in its component in order to use it with a WEB server to perform an authentication.

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.

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.

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 a Container ID that is inserted into a WEB page 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 information about the component himself. Finally, the Identity Container contains the private key of the generated identity, which is much too sensitive information to appear clearly in a WEB page, even if it is positioned in a hidden field.

In order to remedy these flaws, an encrypted container is generated by the identity server, as illustrated in FIG. 4. The term "plaintext 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.

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. A cipher block (cipher block) uses lengths of data that are multiple of an integer (for example 16 bytes for AES), the encrypted container therefore has a length that can be greater than that of the clear container, according to a technique based on so-called padding bytes added as a suffix. The encryption key (K) is inserted in 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. 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 Kp v (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) using a private key associated with an encrypted entity. trusted by the secure component. This relationship is based on the fact that the secure component knows the public key of the trusted entity, and is therefore able to verify this digital signature.

In summary, the delivery of a secure container is based 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 retrieves the certificate of the secure component its public key

- The server (or other entity) builds a secure container with three subsets

1) An encrypted header with the public key of the secure component

2) An encrypted identity container 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. 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 to obtain the information (SSL identity in clear). This information is then interpreted by the secure component.

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 header (402) of fixed length which also contains several 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 public key "root"), retrieved when connecting to the identity server made by the user, and essential to the progress of the step of identity creation.

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 which here plays the role of the Certification Authority (CA), for example at 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 in a virtual address, which means that the contents of the encrypted container is not directly stored in clear 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 in clear, then decrypts this last. 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.

The OpenID 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 OpenID (described above). Indeed, OpenID works on the principle of a secret exchange between the service provider and the OpenID server, as mentioned above. This secret is then used to prove that the user has successfully performed an authentication on the OpenID server mentioned in its OpenID identifier. However, if it turns out that the user managed to cheat at the time of its authentication on the OpenID server, the security of the whole is compromised.

By delegating the management of user authentication to dedicated OpenID servers, the service providers have no architectural constraint on the consideration of the mutual authentication SSL / TLS performed by the secure component. In the same way, an OpenID 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. OpenID. The scenario for the authentication of a user is then the following: the user, previously registered (using his secure component equipped with the SSL stack) on the OpenID identity server described in the previous sections, wishes authenticate with an OpenID compatible service provider. For this, he enters the OpenID 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. It proposes a simple mechanism, such as a voluntary gesture (for example a push of a button) carrying out 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 authentication is successful, the authentication result data is signed by the shared secret, and multiple personal information related to the user's identity is sent to the service provider, in accordance with the privacy policy. 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 itself the access authorization phase of the user to the service. 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.

We have highlighted above the weaknesses of the OpenID architecture with respect to two points:

• Using a login couple (login) / password for

authentication

• Standard implementation of an SSL / TLS session for the protection of information exchanged between the user and the OpenID authentication server. Since it is difficult for a human to recognize a "good" X509 server certificate, there is a risk of phishing. 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.

On the other hand, the OpenID token generated after a successful authentication procedure is also protected by the SSL / TLS session established between the secure component (typically microcontroller) and the OpenID server.

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.

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

1. Authentication platform comprising:

- an identity server,

an authentication server,

- a server (identity or authentication),

- a secure component,

said authentication platform being characterized in that said secure component (typically secure microcontroller) autonomously executes the SSL or TLS protocol, and realizes a protocol

Handshake 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,

2. Authentication platform according to claim 1, characterized in that said identity server comprises means for collecting the certificate of said secure component.

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. 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;

5. Authentication platform according to claim 4, characterized in that said secure component comprises means for analyzing said secure container.

6. Authentication platform according to claim 5, characterized in that said secure component comprises means for:

• decrypt the header with the private key of said secure component; and

• decrypt the encrypted secure container.

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. Authentication platform according to claim 7, characterized in that said information comprises the SSL identity in clear.

9. Authentication platform comprising:

- an identity server,

an authentication server, a computer terminal adapted to execute software, said software enabling the exchange of data between:

- a server (identity or authentication),

- a secure component,