[go: up one dir, main page]

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

Procede de securisation d'une platforme d'authentification, dispositifs materiels et logiciels correspondants Download PDF

Info

Publication number
WO2012156365A1
WO2012156365A1 PCT/EP2012/058928 EP2012058928W WO2012156365A1 WO 2012156365 A1 WO2012156365 A1 WO 2012156365A1 EP 2012058928 W EP2012058928 W EP 2012058928W WO 2012156365 A1 WO2012156365 A1 WO 2012156365A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
identity
secure
component
secure component
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/EP2012/058928
Other languages
English (en)
Inventor
Michel Betirac
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ETHERTRUST
Original Assignee
ETHERTRUST
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ETHERTRUST filed Critical ETHERTRUST
Priority to EP12720216.6A priority Critical patent/EP2710779A1/fr
Publication of WO2012156365A1 publication Critical patent/WO2012156365A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations

Definitions

  • 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.
  • 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.
  • eCommerce electronic commerce
  • 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.
  • login data identifier
  • OTP One Time Password
  • 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.
  • XRI Extensible Resource Identifier
  • 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.
  • 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.
  • 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.
  • PAPE Provider Authentication Policy Extension
  • the user 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.
  • SAML Security Assertion Markup Language
  • 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).
  • arrow 2 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 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.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • the present invention relates, in its most general sense, to an authentication platform comprising:
  • a computer terminal adapted to execute software, said software enabling the exchange of data between:
  • 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,
  • 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
  • said identity server comprises means for collecting the certificate of said secure component.
  • said identity server comprises means for extracting from the certificate of said secure component its public key.
  • said server comprises means for constructing a secure container comprising:
  • a digital signature produced by a private key belonging to a trusted third party identified by the associated public key is a digital signature produced by a private key belonging to a trusted third party identified by the associated public key.
  • said secure component comprises means for analyzing said secure container.
  • said secure component comprises means for:
  • said secure component further comprises means for interpreting information contained in the decrypted secure container.
  • said information comprises the SSL identity in clear.
  • the present invention also relates to an authentication platform comprising: - an identity server,
  • a computer terminal adapted to execute software, said software enabling the exchange of data between:
  • 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,
  • 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
  • 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).
  • FIG. 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.
  • FIG. 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).
  • 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).
  • 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 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 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 Open
  • a secure component typically a secure microcontroller
  • 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.
  • these components typically microcontrollers embody an implementation of the SSL / TLS protocol, usually called SSL / TLS stack or "stack" in Anglo-Saxon terminology.
  • 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.
  • the components typically microcontroller
  • secure generally use a command format defined by ISO7816, represented by the acronym APDU (Application Protocol Data Unit).
  • APDU Application Protocol Data Unit
  • SSL Secure Sockets Layer
  • TLS Transport Layer Security
  • secure typically microcontroller
  • 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.
  • SSL / TLS that is to say HTTPS
  • the establishment of the session 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.
  • 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.
  • 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
  • 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.
  • 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
  • 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.
  • a proxy software based on the Socket library for TCP / IP
  • Java APPLET downloaded and executed in an Internet browser.
  • FIG 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).
  • FIG. 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.
  • secure component typically microcontroller
  • 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 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.
  • 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.
  • proxy which makes it possible to advantageously manage session cookies during authentication on a WEB server
  • 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.
  • identity 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).
  • M2M Machine to Machine
  • 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.
  • 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 identity server The identity server
  • An SSL / TLS identity also called Identity Container
  • An SSL / TLS identity has at least the following fields preceded whenever necessary by one or two bytes giving their length:
  • the root identity of the component is a set of parameters inserted into the component production phase, which includes the following elements:
  • 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.
  • 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).
  • step 303 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.
  • the user 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.
  • the user 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.
  • the user 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.
  • 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.
  • 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.
  • 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.
  • PKCS # 1 standardized methods
  • 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.
  • - Mutual authentication is performed using an SSL / TLS session between a secure component and a server.
  • 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
  • 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.
  • 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.
  • 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.
  • CA Certification Authority
  • the set then constitutes the encrypted container (403) ready to be sent to the component with appropriate write APDUs.
  • 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".
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

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

Description

PROCEDE DE SECURISATION D'UNE PLATFORME D'AUTHENTIFICATION, DISPOSITIFS MATERIELS ET LOGICIELS CORRESPONDANTS
Domaine de l'invention
La présente invention se rapporte au domaine des Technologies de l'Information et de la Communication.
La présente invention se rapporte plus particulièrement à un procédé de sécurisation d'une architecture d'authentification, à des dispositifs matériels et aux logiciels correspondants.
Etat de la technique
L'authentification des internautes sur le WEB est un aspect fondamental de la sécurité des services numériques disponibles sur Internet tels que le commerce électronique (eCommerce) ou la connexion à des ressources de type Cloud Computing.
Dans l'état actuel de l'art, l'identité d'un internaute est généralement un couple de données identifiant (login) / mot de passe, parfois renforcé à l'aide d'un dispositif nommé One Time Password (OTP) dans la terminologie anglo- saxonne.
L'usage généralisé de mots de passe pour accéder à des services internet est sujet à des attaques qualifiées de phishing, qui ont pour but 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. Une autre contrainte pour l'internaute est la définition et la mémorisation de multiples mots de passe. Les technologies dites de Single Sign On (SSO) ou de fédérations d'identités, ont pour objectif de réduire le nombre d'identifiants requis par les services Internet. Cependant il est évident que l'existence d'un mot de passe unique pour l'accès à de multiples ressources numériques augmente le risque de piratage via des logiciels malveillants (chevaux de Troie) ou procédés de phishing.
Plateforme de Single Sign On
OpenID 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 OpenID et qui ne dépend pas du fournisseur de services sur lequel l'utilisateur souhaite s'authentifier. L'infrastructure OpenID 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 OpenID lui-même (103). Les méthodes d'authentification sont multiples et dépendent des serveurs OpenID. Elles sont basées sur des couples login / mot de passe, ou sur des méthodes plus robustes impliquant par exemple l'utilisation de carte à puce ou de biométrie.
La première étape de l'architecture OpenID implique l'enregistrement d'un utilisateur avec un serveur OpenID. Une fois le compte créé, il reçoit un identifiant OpenID spécifique à ce compte sous la forme d'un XRI (extensible Resource Identifier), dans lequel apparaît l'adresse du serveur OpenID. Selon l'état de l'art actuel cette opération est protégée par une session HTTPS, l'authenticité du serveur repose sur la vérification par l'utilisateur (par le navigateur WEB qu'il utilise en fait) de la validité du certificat X509 du serveur.
Au terme de cette première étape, les trois éléments constitutifs de la plateforme OpenID interagissent de la manière suivante, illustrée par la figure 1 . L'utilisateur qui souhaite s'authentifier auprès d'un fournisseur de services sélectionne (lorsque celle-ci est disponible) l'option d'authentification par protocole OpenID. Il renseigne son identifiant OpenID (flèche 1 ). L'utilisateur est redirigé (au sens HTTP, par exemple à l'aide d'un javascript exécuté automatiquement) vers le serveur OpenID 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 d'authentification de la part des serveurs OpenID, sous réserve de quoi l'authentification peut être refusée par le fournisseur de services.
Lorsque l'authentification est effectuée (flèche 5), l'utilisateur est redirigé (au sens HTTP, par exemple en utilisant un statut de réponse 302) vers le 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 (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 OpenID.
La sécurité du lien entre le serveur OpenID 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 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 OpenID n'ont a priori aucun lien de confiance préalable.
L'architecture OpenID réalise également l'authentification unique (Single Sign On).
Problèmes de sécurité du standard OpenID
La simplicité d'utilisation de l'architecture OpenID, 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 OpenID, où un attaquant peut gagner accès à plusieurs services à la fois en ayant usurpé un seul compte.
Or, la seule sécurité garantie par OpenID est celle de la validité du résultat de l'authentification auprès du serveur OpenID, 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 OpenID d'implémenter ces méthodes fortes. De fait, la majorité des serveurs OpenID existants se limitent à proposer une authentification de type identifiant / mot de passe, c'est- à-dire d'un niveau de sécurité très faible.
Les attaques contre les serveurs OpenID 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 OpenID a besoin d'augmenter ses garanties de sécurité. L'utilisation du protocole SSL/TLS pourrait ainsi être rendu obligatoire pour tout serveur OpenID. 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 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.
Afin de combler les failles potentielles de l'architecture OpenID, 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 sécurisation de l'architecture qui maximise la sécurité tout en respectant les standards de l'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 et logiques).
Par ailleurs, un serveur OpenID 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 l'architecture globale doit être compatible avec cette contrainte, notamment en stockant les identités générées dans le composant sécurisé.
On connaît dans l'état de la technique les publications scientifiques suivantes : • « Convergent identity : Seamless OPENID services for 3G dongles using SSL enabled USIM smart cards » de Pascal URIEN (Consumer Communications and Networking Conférence - CCNC - 201 1 - IEEE - 9 janvier 201 1 ) ; · " An OpenID provider based on SSL smart cards" de Pascal URIEN (Consumer Communications and Networking Conférence - CCNC - 2010 - IEEE - 9 janvier 2010) ; et
• " TLS-Tandem : a smart card for Web applications » de Pascal URIEN (Consumer Communications and Networking Conférence - 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 œuvre du procédé.
Exposé de l'invention
La présente invention concerne un procédé d'authentification qui résiste au phishing, et sa mise en œuvre dans le contexte de la fédération d'identité, avec l'exemple non limitatif de la norme OpenID. La plateforme d'authentification décrite par l'invention comporte quatre éléments.
1 - Un composant matériel sécurisé, couramment un composant (typiquement microcontrôleur) sécurisé (qualifié de «tamper résistant device», ou encore de «secure élément») qui exécute un logiciel intégrant le protocole TLS/SSL dans un environnement sécurisé physiquement et logiquement.
2- Un logiciel nommé Agent Utilisateur (User Agent) qui réalise l'interface (la glue logique) entre le navigateur Internet (Browser) et le composant
(typiquement microcontrôleur) sécurisé. 3- Un serveur d'identité qui génère des identités et gère leur cycle de vie. Ces informations sont téléchargées via internet dans des structures de données sécurisés, dénommées container dans ce document, qui ne peuvent être déchiffrés que par le composant sécurisé (typiquement un microcontrôleur sécurisé).
4- Un serveur d'authentification de type Single Sign On, par exemple un serveur OpenID, qui dialogue via le Agent Utilisateur (User Agent) avec le composant (typiquement microcontrôleur) sécurisé. 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, 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é.
Selon un mode de réalisation, ledit serveur d'identité comporte des moyens pour collecter le certificat dudit composant sécurisé. Avantageusement, ledit serveur d'identité comporte des moyens pour extraire du certificat dudit composant sécurisé sa clé publique.
Selon un mode de réalisation, ledit serveur comporte des moyens pour construire un containeur sécurisé comportant :
• un entête chiffré avec la clé publique du composant sécurisé ;
• un container d'identité chiffré avec une clé 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 analyser ledit containeur sécurisé.
Selon un mode de réalisation, ledit composant sécurisé comporte des moyens pour :
• vérifier ladite signature avec une clé publique du tiers 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 moyens pour interpréter des informations contenues dans le containeur sécurisé décrypté.
De préférence, lesdites informations comprennent l'identité SSL en clair.
La présente invention se rapporte également à une plateforme d'authentification comportant : - un serveur d'identité,
- un serveur d'authentification,
- un terminal informatique adapté à exécuter un logiciel, ledit logiciel permettant l'échange de données entre :
- un serveur (d'identité ou d'authentification),
- un composant sécurisé,
- et un navigateur disponible sur un terminal (ordinateur personnel, téléphone mobile) d'un client,
ladite plateforme d'authentification étant caractérisée en ce que ledit composant sécurisé (typiquement microcontrôleur sécurisé) exécute de manière autonome le protocole SSL ou TLS, et réalise un protocole Handshake lors de l'ouverture d'une session SSL/TLS entre le terminal du client et le serveur d'authentification, ledit composant sécurisé étant fabriqué avec un premier certificat et une clé privée,
et en ce qu'elle comporte en outre des moyens pour télécharger à partir du serveur d'authentification, un ensemble de données chiffré avec la clé publique présente dans le certificat du composant sécurisé et signé avec une clé privée d'une autorité de certification reconnue par le composant, en mettant en oeuvre une session SSL/TLS ouverte par le composant sécurisé.
Brève description des dessins
On comprendra mieux l'invention à l'aide de la description, faite ci-après à titre purement explicatif, d'un mode de réalisation de l'invention, en référence aux Figures dans lesquelles : La Figure 1 illustre la structure typique d'une plateforme d'authentification OpenID, qui comporte l'utilisateur (101 ), le fournisseur de services (102), et le serveur OpenID 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 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 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 OpenID. Ce dernier est mis en œuvre grâce à un 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 OpenID (504).
La Figure 6 détaille la structure logique d'un Agent Utilisateur (User 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. Description détaillée des modes de réalisation de l'invention
La présente invention réalise une sécurisation globale d'une architecture d'authentification telle que OpenID, tout en assurant la gestion des identités. Elle se compose de quatre entités, décrites à la Figure 5, un composant sécurisé, typiquement un microcontrôleur sécurisé (501 ), un logiciel Agent Utilisateur ou User Agent (502) exécuté sur un terminal (PC, smartphone, ...), un serveur d'identité (503), et un serveur d'authentification OpenID (504). Le composant sécurisé
Un composant sécurisé, typiquement un microcontrôleur sécurisé, est un composant électronique durci d'un point de vue sécuritaire tant du point de vue physique que logique, tels que les références actuelles ST22 ou ST23 de la 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.
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 de type FPGA, microprocesseurs ou DSP... Sans que cette liste soit exhaustive.
Les composants (typiquement microcontrôleur) sécurisés utilisent généralement un format de commandes défini par la norme ISO7816, représenté par le sigle APDU (Application Protocol Data Unit).
Secure Sockets Layer (SSL), est un protocole de sécurisation des échanges sur Internet, développé par la société Netscape avec deux versions majeures SSL version 2 et SSL version 3. Depuis 2001 il est normalisé par l'IETF (www.ietf.org) sous le sigle TLS (Transport Layer Security) par les RFC 2246, RFC 4346, RFC 5246, RFC 4347. Dans ce document les termes SSL et TLS se réfèrent à ces différents standards. Cette implémentation est réalisée de telle sorte que la taille du code (de l'ordre de quelques dizaines de KiloOctets) puisse tenir dans la mémoire non volatile des composants les plus petits. Elle peut être intégrée à tout type de composant (typiquement microcontrôleur) sécurisé, que ce soit une carte SIM, une JavaCard, un composant NFC, un processeur SmartMX. Contrairement 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. 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 composant sécurisé.
La pile SSL/TLS est implémentée sur la forme d'une machine à états, aussi bien en mode «full» qu'en mode «résume» (encore dénommé «abbreviated»), dans laquelle tous les calculs cryptographiques du protocole 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é. Par ailleurs, les paquets SSL/TLS peuvent être avantageusement encapsulés via le protocole EAP, selon les spécifications de la norme EAP-TLS (RFC 2716, RFC 5216), assurant ainsi un transport des paquets en mode datagramme et conférant ainsi une sécurité accrue. La norme EAP-TLS impose par ailleurs une authentification mutuelle entre client et serveur (le client s'authentifie à l'aide du message Verify). Le certificat X509 client est stocké dans un Container d'identité (détaillé en section 3-C) sur le composant sécurisé, ainsi que sa clé privée.
Une fois la phase de Handshake achevée, les valeurs des clés éphémères contenues dans le "KeyBlocks" et dérivées du Master Secret peuvent être ou non exportées sur le terminal client, de sorte que le chiffrement symétrique de la session SSL/TLS peut être réalisé soit par le composant sécurisé, soit le terminal en fonction des besoins de l'application. Ce choix ne modifie pas le procédé de sécurisation de la plateforme OpenID décrit dans ce document.
Une pile SSL/TLS embarquée de manière avantageuse dans un composant sécurisé permet, par la nature de ce dernier, de prévenir les failles d'implémentation logicielle de SSL/TLS présentes habituellement sur les terminaux clients, et évite ainsi une modification potentielle du code de cette dernière ou la récupération de données sensibles par un tiers, ou un logiciel malveillant (malware) tel qu'un cheval de Troie.
L'Agent Utilisateur (User Agent)
Le logiciel Agent Utilisateur (User Agent) réalise la «glue logique» (interface logique) entre un serveur WEB (serveur d'identité ou serveur OpenID) et le composant (typiquement microcontrôleur) sécurisé. Il est exécuté dans un terminal informatique tel qu'ordinateur personnel, tablette ou smartphone, sous la supervision de systèmes d'exploitation variés (Windows, Android, RIM, Apple, Linux, ...). II réalise la communication entre le terminal client, équipé d'un navigateur WEB et le composant sécurisé, mais également le lien entre le composant (typiquement microcontrôleur) sécurisé et le serveur WEB lors d'une connexion SSL/TLS. Le logiciel User Agent est compatible avec toutes sortes d'interfaces physiques et logiques vers le composant sécurisé, notamment bus USB, PC/SC, AT-CSIM, port série, sans contact: NFC, BLUETOOTH, Wi-Fi„ sans que cette liste soit limitative. Ainsi, les composants (typiquement microcontrôleurs) sécurisés peuvent communiquer de manière transparente vers un serveur WEB pour établir une session SSL/TLS. Le code source de la pile SSL/TLS est adapté à chaque type d'interface, par exemple en utilisant des tailles variables de paquets EAP.
Le logiciel Agent Utilisateur (User Agent) peut être réalisé au moyen d'un logiciel proxy (basé sur la bibliothèque Socket pour TCP/IP), ou sous d'autres formes telles qu'un APPLET Java téléchargé et exécuté dans un navigateur Internet. Dans la suite de ce document, les architectures correspondant à ces deux exemples seront détaillées, sans que ces exemples constituent une limitation pour l'implémentation du logiciel Agent Utilisateur (User Agent).
La Figure 6 illustre la structure logique d'un Agent Utilisateur (User Agent) «proxy». Le User Agent (602) gère un socket serveur (604) qui réalise l'interface avec le navigateur WEB (601 ), et un socket client (605) qui établit une connexion TCP avec un serveur distant (603). Il gère également un port de communication avec le composant (typiquement microcontrôleur) sécurisé (606) qui peut ainsi échanger des données avec le navigateur (601 ) et le serveur (603).
La Figure 7 présente la structure logique d'un Agent Utilisateur (User Agent) «APPLET Java». Le navigateur WEB (701 ) télécharge une page HTML contenant un APPLET (702) signé (par exemple avec l'outil jarsigner) et stocké sur un serveur (703). Cet APPLET établit des connexions TCP avec le serveur (703) à l'aide d'un socket client fourni par la classe JAVA Socket; il peut également échanger des informations avec le composant (707) sécurisé (typiquement microcontrôleur) au moyen de la classe javax.smartcardio (706) disponible à partir de la version 1 .6 du langage JAVA. La classe netscape.javascript.JSObject supporté par la plupart des navigateurs WEB permet d'exécuter un JavaScript associé à la page HTML chargé par le navigateur (à l'aide de la méthode netscape.javascript.JSObject.eval), et en particulier d'effectuer une redirection HTTP après avoir inséré un cookie.
Le logiciel User Agent convertit des requêtes HTTP particulières en une suite de commandes APDUs, définies par le standard ISO 7816, par exemple l'URL http://127.0.0.1 :8080/~apdu?=cmdi&=cmd2...&=cmdn 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. Afin de réaliser les ouvertures de connexion SSL/TLS par l'intermédiaire de l'Agent Utilisateur (dans ce cas «proxy»), l'URL exécutée par un navigateur WEB possède un format spécifique, du type : http://127.0.0.1 :8080/~url=serveur.com
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 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.
Dans le cas où les clés temporaires de session sont exportées sur le poste client (flèche 3), le composant n'intervient plus dans la suite de la session SSL/TLS, à savoir la phase d'échange de données cryptées (flèche 4) entre client et serveur. Sinon, c'est ce dernier qui réalise les calculs cryptographiques nécessaires à l'échange de données chiffrées.
L'une des alternatives possibles à l'utilisation d'un proxy, qui permet notamment de gérer avantageusement les cookies de session lors de l'authentification sur un serveur WEB, est un Applet Java délivrant les mêmes services que le proxy. C'est alors l'Applet qui fait l'interface avec le composant sécurisé et le navigateur, grâce par exemple à la classe netscape.javascript.JSObject disponible sur les navigateurs WEB, qui permet d'exécuter des javacripts embarqués sur une page HTML, et peut être instancié selon le procédé dénommé "Java Reflection".
Le composant sécurisé embarquant la pile SSL/TLS stocke également une identité, qui peut être de type «client» ou «serveur», c'est-à-dire réalisant le 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 suite de ce document, nous supposerons que l'identité utilisateur est de type «client».
Le format de cette identité (aussi appelée Container d'identité dans ce document) est décrit ci-dessous. Cette identité contient, entre autres éléments, 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 composant, soit de manière distante via une interface WEB avec un serveur dédié. L'identité est produite à la demande de l'utilisateur. Celui-ci doit simplement saisir un nom d'utilisateur (son nom ou bien un pseudonyme, par exemple) afin qu'un Container d'identité soit généré, qui contienne un certificat dont, par exemple, l'attribut Common Name corresponde au nom qu'il a saisi auparavant.
L'interface WEB de chargement des identités est construite sur l'utilisation conjointe de l'Agent Utilisateur (User Agent, proxy ou applet WEB) et de la technologie AJAX (Asynchronous Javascript and XML), en particulier la mise en œuvre 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 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 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é).
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 authentifié auparavant afin que la page contenant l'interface AJAX ait une URL du type : http://127.0.0.1 :8080/~url=server.com/download_identity.html. Selon les cas considérés, il peut être possible de stocker une seule ou plusieurs identités sur un composant. Dans le cas où une seule identité est stockée, celle-ci peut être mise à jour (c'est-à-dire supprimée puis réécrite) par cette interface, en utilisant un APDU approprié à cette fin. Dans le cas du stockage de plusieurs identités, on juxtapose plusieurs Containers d'identités dans le composant en générant dynamiquement une adresse d'écriture adéquate dans le composant lors de la génération de l'identité. Dans ce cas, le choix de l'emplacement de l'identité à charger dans le composant peut être proposé à l'utilisateur lors de sa demande de génération d'identité.
Le serveur d'identité
Une identité SSL/TLS (encore appelée Container d'identité), telle qu'elle est stockée dans le composant, comporte au moins les champs suivants, 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 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é). Par ailleurs, les clés publiques des autorités de certification acceptées par le composant doivent avoir été stockées au préalable dans le code du protocole SSL/TLS embarqué.
L'identité racine du composant est un ensemble de paramètres inséré 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, 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. 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é. 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. 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). 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 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.
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és présentes dans son composant afin d'en faire l'utilisation auprès d'un serveur WEB pour réaliser une authentification.
Lorsque l'utilisateur souhaite créer une identité, il doit saisir le nom donné à cette identité, et pourra par exemple saisir un numéro qui déterminera l'adresse de stockage de l'identité dans la mémoire non volatile du composant. Les identités présentes dans le composant doivent être répertoriées également sur la base de données du serveur d'identités afin d'assurer la cohérence des actions de l'utilisateur. De manière identique, lorsqu'une identité présente sur le composant est supprimée ou réécrite, le serveur doit être mis à jour en conséquence afin d'être synchronisé avec les données présentes sur le composant de l'utilisateur.
Enfin, dans le cas où l'utilisateur a perdu son composant, il doit signaler cet état de fait aux administrateurs du serveur d'identités (dans le cas où le composant est arrivé en fin de vie, cela sera automatiquement détecté par le serveur), afin que soient révoqués tous les certificats X509 émis lors de la génération des identités SSL/TLS de cet utilisateur. La clé publique de l'identité «racine» du composant est alors placée dans une liste noire (étape 306). Si une tentative de connexion était réalisée à partir de cette identité, celle-ci serait refusée par le serveur d'identité. Toutefois, l'utilisateur peut garder son ancien compte sur le serveur d'identité. En effet, lorsqu'il aura en sa possession un nouveau composant, avec une nouvelle identité «racine», il lui faudra faire la preuve de son identité auprès des administrateurs du serveur, à l'aide des informations personnelles saisies lors de son enregistrement sur le serveur. Si ces dernières sont valides, la nouvelle clé publique du composant pourra être liée à son ancien compte sur ce serveur d'identités.
La sécurité de la gestion des identités chargées depuis le serveur WEB vers le composant sécurisé repose sur l'utilisation d'un chiffrement rendant impossible un chargement illégal d'identité dans le composant. La mise en œuvre 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 positionne dans un champ caché.
Afin de remédier à ces failles, un Container chiffré est généré par le serveur d'identité, de la manière illustrée par la Figure 4. 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 paramètres dont en particulier un alias de l'identité SSL.
Le container en clair est chiffré par un algorithme cryptographique symétrique, par exemple AES, à l'aide d'une clé (nommée K sur la figure 401 ) dont la valeur est établie de manière aléatoire. Un chiffrement en mode bloc (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. La clé de chiffrement (K) est insérée dans un entête (402), qui contient également plusieurs informations telles que la nature de l'algorithme de chiffrement utilisé, la longueur du container en clair, et l'algorithme de signature utilisé. Lors de l'établissement de la session SSL/TLS entre le composant sécurisé et le serveur, ce dernier a collecté le certificat du composant sécurisé qui contient la clé publique Kpub. Cette clé permet de réaliser le chiffrement asymétrique de l'entête 402 (par exemple via l'algorithme RSA) selon des procédés standardisés tels que PKCS#1 . En l'état de l'art actuel, seule la connaissance de la clé privé Kp v (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 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é connaît la clé publique de l'entité de confiance, et qu'il est en conséquence capable de vérifier cette signature numérique.
En résumé, la délivrance d'un container sécurisé s'appuie sur les éléments suivants
- Une mutuelle authentification est réalisée à l'aide d'une 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 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.
3) Une signature numérique produite par une clé privée appartenant à un tiers de confiance identifié par la clé publique associée. Le container sécurisé est analysé par le composant sécurisé selon le scénario suivant :
1 ) La signature est vérifiée avec la clé publique du tiers de confiance, stockée dans le composant sécurisé.
2) Si l'opération précédente est réalisée avec succès, l'entête est déchiffrée avec la clé privée du composant sécurisé. La nature de l'algorithme de chiffrement symétrique et sa clé sont alors déterminés de même que la taille du container en clair.
3) Le container chiffré est décrypté, ce qui permet d'obtenir les informations (identité SSL en clair). Ces informations sont alors interprétées par le composant sécurisé.
Le Container en clair (401 ) est d'abord chiffré par le serveur à l'aide d'une clé d'un algorithme symétrique (par exemple AES). Cette clé est placée 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 connexion au serveur d'identités réalisée par l'utilisateur, et indispensable au déroulement de l'étape de création d'identité.
Enfin, l'en-tête chiffré concaténé avec le Container d'identité chiffré par la clé symétrique est signé numériquement avec la clé privée du serveur 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 mémoire non volatile du composant sécurisé. Il doit auparavant être vérifié par le composant. Pour cela, celui-ci vérifie d'abord la signature numérique, puis, si celle-ci est correcte, il déchiffre l'en-tête du Container avec sa clé privée «racine». Il récupère de cet en-tête la clé symétrique utilisée précédemment pour chiffrer l'Identité SSL/TLS qui était en clair à l'origine, puis déchiffre cette dernière. Si l'ensemble des opérations s'est déroulé sans erreur, le Container en clair est alors écrit en mémoire non volatile à l'emplacement sélectionné par l'utilisateur (emplacement stocké notamment dans l'en-tête soumis au composant). En revanche, si une erreur se produit à l'une des étapes précédentes, un statut d'erreur est renvoyé vers le navigateur via l'Agent Utilisateur (User Agent, typiquement le proxy), et le Container d'identité est rejeté sans être écrit en mémoire non volatile.
Le Serveur d'Authentification OpenID
La mise en œuvre 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'OpenID (décrite ci-dessus). En effet, OpenID fonctionne sur le principe d'un échange de secret entre le fournisseur de services et le serveur OpenID, ainsi que mentionné ci-dessus. Ce secret est ensuite utilisé pour prouver que l'utilisateur a bien réalisé une authentification sur le serveur OpenID mentionné dans son identifiant OpenID. S'il s'avère toutefois que l'utilisateur est parvenu à tricher au moment de son authentification sur le serveur OpenID, la sécurité de l'ensemble est compromise.
En délégant la gestion de l'authentification des utilisateurs à des serveurs OpenID 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 OpenID 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 OpenID. 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 OpenID décrit dans les sections précédentes, souhaite s'authentifier auprès d'un fournisseur de services compatible OpenID. Pour cela, il saisit l'identifiant OpenID 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. 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 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 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.
Nous avons souligné ci-dessus les faiblesses de l'architecture OpenID relativement aux deux points suivants:
• Utilisation d'un couple identifiant (login) / mot de passe pour
l'authentification
• Mise en œuvre standard d'une session SSL/TLS pour la protection des informations échangées entre l'utilisateur et le serveur d'authentification OpenID. Puisqu'il est difficile pour un humain de reconnaître un «bon» certificat X509 de serveur, il y a risque de phishing. La présente invention, décrite ci-dessus, permet une authentification forte basée sur une mutuelle authentification entre un composant (typiquement microcontrôleur) sécurisé et le serveur d'authentification. Le risque de vol de mot de passe disparait et le phishing est rendu difficile grâce à la vérification du certificat du serveur par le composant (typiquement microcontrôleur) sécurisé.
D'autre part, le jeton OpenID 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 OpenID.
La délégation de la gestion de la procédure d'authentification à un composant (typiquement microcontrôleur) sécurisé crée un nouveau problème de sécurité lié à l'éventuelle perte ou vol de ce dispositif. Les mécanismes explicités ci-dessus permettent, en séparant l'identité du composant qui est unique et celle définie par l'utilisateur, la gestion d'une procédure de révocation du composant sécurisé, ainsi qu'une procédure de remise en service des identités précédemment générées sur un nouveau composant.
L'invention est décrite dans ce qui précède à titre d'exemple. Il est entendu que l'homme du métier est à même de réaliser différentes variantes de l'invention sans pour autant sortir du cadre du brevet.

Claims

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

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP12720216.6A EP2710779A1 (fr) 2011-05-16 2012-05-14 Procede de securisation d'une platforme d'authentification, dispositifs materiels et logiciels correspondants

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1101481A FR2975551B1 (fr) 2011-05-16 2011-05-16 Procede de securisation d'une architecture d'authentification, dispositifs materiels et logiciels correspondants
FR1101481 2011-05-16

Publications (1)

Publication Number Publication Date
WO2012156365A1 true WO2012156365A1 (fr) 2012-11-22

Family

ID=46052792

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2012/058928 Ceased WO2012156365A1 (fr) 2011-05-16 2012-05-14 Procede de securisation d'une platforme d'authentification, dispositifs materiels et logiciels correspondants

Country Status (3)

Country Link
EP (1) EP2710779A1 (fr)
FR (2) FR2975551B1 (fr)
WO (1) WO2012156365A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111212429A (zh) * 2019-12-11 2020-05-29 全球能源互联网研究院有限公司 一种移动终端的安全接入系统及方法
US10681085B2 (en) * 2017-10-16 2020-06-09 International Business Machines Corporation Quick transport layer security/secure sockets layer connection for internet of things devices
CN113010880A (zh) * 2021-02-08 2021-06-22 上海新时达电气股份有限公司 电梯配件认证方法、系统、服务器和存储介质
CN116545995A (zh) * 2023-05-10 2023-08-04 北京上元信安技术有限公司 基于HTTPS的Portal认证方法、系统、设备及存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2791159A1 (fr) 1999-03-15 2000-09-22 Bull Cp8 Procede d'acces a un objet a l'aide d'un navigateur de type "web" cooperant avec une carte a puce et architecture pour la mise en oeuvre du procede
US7000108B1 (en) * 2000-05-02 2006-02-14 International Business Machines Corporation System, apparatus and method for presentation and manipulation of personal information syntax objects

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2791159A1 (fr) 1999-03-15 2000-09-22 Bull Cp8 Procede d'acces a un objet a l'aide d'un navigateur de type "web" cooperant avec une carte a puce et architecture pour la mise en oeuvre du procede
US7000108B1 (en) * 2000-05-02 2006-02-14 International Business Machines Corporation System, apparatus and method for presentation and manipulation of personal information syntax objects

Non-Patent Citations (7)

* Cited by examiner, † Cited by third party
Title
PASCAL URIEN: "An Open/D provider based on SSL smart cards", CONSUMER COMMUNICATIONS AND NETWORKING CONFERENCE - CCNC - 2010 - IEEE, 9 January 2010 (2010-01-09)
PASCAL URIEN: "Convergent identity: Seamless OPENID services for 3G dongles using SSL enabled USIM smart cards", CONSUMER COMMUNICATIONS AND NETWORKING CONFERENCE - CCNC - 2011 - IEEE, 9 January 2011 (2011-01-09)
PASCAL URIEN: "Convergent identity: Seamless OPENID services for 3G dongles using SSL enabled USIM smart cards", CONSUMER COMMUNICATIONS AND NETWORKING CONFERENCE (CCNC), 2011 IEEE, IEEE, 9 January 2011 (2011-01-09), pages 830 - 831, XP031866064, ISBN: 978-1-4244-8789-9, DOI: 10.1109/CCNC.2011.5766616 *
PASCAL URIEN: "TLS-Tandem : a smart card for Web applications", CONSUMER COMMUNICATIONS AND NETWORKING CONFERENCE - CCNC - 2009 - IEEE, 10 January 2009 (2009-01-10)
PASCAL URIEN: "TLS-Tandem: A Smart Card for WEB Applications", CONSUMER COMMUNICATIONS AND NETWORKING CONFERENCE, 2009. CCNC 2009. 6TH IEEE, IEEE, PISCATAWAY, NJ, USA, 10 January 2009 (2009-01-10), pages 1 - 2, XP031425704, ISBN: 978-1-4244-2308-8 *
See also references of EP2710779A1 *
URIEN P: "An OpenID Provider Based on SSL Smart Cards", CONSUMER COMMUNICATIONS AND NETWORKING CONFERENCE (CCNC), 2010 7TH IEEE, IEEE, PISCATAWAY, NJ, USA, 9 January 2010 (2010-01-09), pages 1 - 2, XP031642923, ISBN: 978-1-4244-5175-3 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10681085B2 (en) * 2017-10-16 2020-06-09 International Business Machines Corporation Quick transport layer security/secure sockets layer connection for internet of things devices
CN111212429A (zh) * 2019-12-11 2020-05-29 全球能源互联网研究院有限公司 一种移动终端的安全接入系统及方法
CN113010880A (zh) * 2021-02-08 2021-06-22 上海新时达电气股份有限公司 电梯配件认证方法、系统、服务器和存储介质
CN116545995A (zh) * 2023-05-10 2023-08-04 北京上元信安技术有限公司 基于HTTPS的Portal认证方法、系统、设备及存储介质

Also Published As

Publication number Publication date
EP2710779A1 (fr) 2014-03-26
FR2975551B1 (fr) 2013-09-27
FR2975551A1 (fr) 2012-11-23
FR2975518B1 (fr) 2015-10-23
FR2975518A1 (fr) 2012-11-23

Similar Documents

Publication Publication Date Title
CN110326267B (zh) 具有替代数字证书的网络安全系统、方法及存储介质
EP3476097B1 (fr) Technique de téléchargement d'un profil d'accès à un réseau
EP2820795B1 (fr) Procede de verification d'identite d'un utilisateur d'un terminal communiquant et systeme associe
EP2153613A2 (fr) Procede de securisation d'echange d'information, dispositif, et produit programme d'ordinateur correspondant
EP2567502A2 (fr) Procede d'authentification d'un utilisateur requerant une transaction avec un fournisseur de service
EP3174241B1 (fr) Méthode d'établissement d'une communication sécurisée de bout en bout entre le terminal d'un utilisateur et un objet connecté
FR2877521A1 (fr) Dispositif, procede, programme et support de distribution d'informations, d'initialisation, dispositif, procede, programme et support de transfert d'initialisation d'authentification et programme de reception ...
EP2012907A2 (fr) Procede de protection d'identite, dispositifs, et produit programme d'ordinateur correspondants
FR2930391A1 (fr) Terminal d'authentification d'un utilisateur.
FR2964812A1 (fr) Procede d'authentification pour l'acces a un site web
FR2997525A1 (fr) Procede de fourniture d’un service securise
EP3375133B1 (fr) Procede de securisation et d'authentification d'une telecommunication
FR3066666A1 (fr) Procede de securisation d'une communication sans gestion d'etats
WO2020260136A1 (fr) Procédé et système de génération de clés de chiffrement pour données de transaction ou de connexion
EP2710779A1 (fr) Procede de securisation d'une platforme d'authentification, dispositifs materiels et logiciels correspondants
EP4241416A1 (fr) Procede de delegation d'acces a une chaine de blocs
EP2056565A1 (fr) Procédé d'authentification d'un utilisateur accédant à un serveur distant à partir d'un ordinateur
FR2946822A1 (fr) Dispositif et procede d'acces securise a un service distant.
EP3673633B1 (fr) Procédé d'authentification d'un utilisateur auprès d'un serveur d'authentification
EP2409474A1 (fr) Procédé de production de données de sécurisation, dispositif et programme d'ordinateur correspondant
Urien et al. A new convergent identity system based on eap-tls smart cards
EP3503500B1 (fr) Procédé pour créer une signature électronique à distance au moyen du protocole fido
Rhodes et al. TLS/SSL
FR2901438A1 (fr) Un procede d'embarquement d'un protocole securise dans des cartes a puces, des capteurs et des objets intelligents
EP3360293A1 (fr) Moyens de gestion d'accès à des données

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12720216

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2012720216

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE