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)

Applications Claiming Priority (2)

Publications (1)

Family

ID=46052792

Family Applications (1)

Country Status (3)

Families Citing this family (2)

Family Cites Families (2)

• 2011
  • 2011-05-16 FR FR1101481A patent/FR2975551B1/fr not_active Expired - Fee Related
• 2012
  • 2012-05-14 WO PCT/EP2012/058928 patent/WO2012156365A1/fr active Application Filing
  • 2012-05-14 FR FR1254381A patent/FR2975518B1/fr active Active
  • 2012-05-14 EP EP12720216.6A patent/EP2710779A1/de not_active Withdrawn

Non-Patent Citations (2)

Also Published As

Similar Documents

Legal Events