FR3041195A1 - METHOD OF ACCESSING ONLINE SERVICE USING SECURE MICROCIRCUIT AND SECURITY TOKENS RESTRICTING THE USE OF THESE TOKENS TO THEIR LEGITIMATE HOLDER - Google Patents

Abstract

A method for accessing a target server online from a client application by means of a secure microcircuit, a pseudonym and a security token containing attributes, said token being obtained from a server generating tokens, which can be either an attribute provider or an identity provider, characterized in that the client application obtaining the token is unable to grant the benefit of said security token to another client application, and that the method comprises the following steps: - the provision of users by manufacturers of microcircuits microcircuits secured to particular characteristics, - the creation of an account on a target server by means of a pseudonym and such a secure microcircuit, - the creation of an account on a server generating tokens by means of a pseudonym and such a secure microcircuit, - the request for a n security token to a server generating tokens using a pseudonym and such a secure microcircuit, - the generation of a security token by the server generating tokens, and - the acceptance of the token of security by the target server.

Description

Description Technical Area

The present invention relates to a device for accessing an online service by means of pseudonyms and attributes contained in security tokens.

The method particularly relates to access to a server via a network, for example via the Internet, by a computer entity called a "client application", which can represent a natural person or a legal person, in the "client-server" paradigm. .

PRIOR ART Generally, the access of a client to a server is conditioned by the presentation of certain "attributes" of the user who, in the absence of his complete identity, reveal certain personal data of this person. For example, there are situations where it is desirable to be able to demonstrate that one is over 18 years old, without revealing one's date of birth, name or surname. Access to a server by means of attribute presentation is sometimes known by the acronym ABC: "Attribute Based Credentials".

In terms of security, it has long been considered that there are only two kinds of people: the users of a system located inside this system and the attackers located outside this system. If this vision has been useful and still useful, it is not enough.

Many systems have been described in the literature and some are currently being tested with the financial support of the European Commission. These systems assume that users are always "honest". Unfortunately, this hypothesis does not resist in everyday life.

In fact, we must also consider people who use a system located "inside this system" who would agree to collaborate together for a few moments so that one of the people who would be able to demonstrate to a server a quality that she owns (for example, that she is of age) can transfer this quality to another person who does not possess it (for example because she is a minor) so that this other person is then able to demonstrate to a server a quality she does not have.

Whatever the sophistication of the cryptographic algorithms implemented, it is strictly impossible with a solution implementing only software to prevent the transfer of a quality of a person who owns it for the benefit of a person who does not do not have it. Hence the need to implement a hardware component, in this case a secure microcircuit, also known as the "secure element", such as a microcircuit card or a module. security. Some systems which have been described in the literature and which are currently being tested make it possible to implement a microcircuit.

However, the way in which this secure microcircuit is implemented does not make it possible to prevent the transfer of a quality (that is, of an attribute) from the person who owns it to a person who does not possess it.

Among the various solutions proposed, we know the ABC4Trust project that brings together two solutions: the "U Prove" solution from Microsoft and the "Identity Mixer" (IdeMix) solution from IBM Zurich. Even with the implementation of a secure microcircuit, at least as described in the documentation available to the public in May 2015, neither of these two solutions can prevent the transfer of a quality from the person who owns it. to someone who does not have it.

In addition, the working group 16 (WG 16) of TC 224 of the European Committee for Standardization (CEN) elaborated in April 2015 a document of 372 pages divided into 5 parts which is entitled: "Application Interface for secure elements used as Qualified electronic Signature (Seal-) Creation Devices ". This document, which describes the implementation of "secure elements", describes security protocols - and not application interfaces like its wrongly identical title - and various security services that have nothing to do with its title. The document has five parts.

Part 4, entitled: "Privacy Specifies Protocols" allows, after 28 exchanges, to support a pseudonymous authentication mechanism called "Restricted identification," which is described in section 3.3, and allows the transfer of attributes, after a total 45 exchanges.

This mechanism, besides being cumbersome and complex, requires the implementation of a specific architecture that requires server-based certificates that can be verified by microcircuit cards (called CV certificates for "Card Verifiable Certificate") in addition to X certificates. .509 which are used to establish HTTPS type links. The basic principle retained is to carry out all sensitive exchanges with the microcircuit card by means of secure channels, which does not make it possible to modify the exchanges without this being detected; but this does not allow the user to see the content of the exchanges made by his card with the outside world. One of the basic principles of privacy by design ("privacy by design" in English) is therefore not respected: the user does not have the opportunity to agree to allow the transfer of each attribute: he must trust the rights that are contained in a CV certificate and can not modify them.

The rights are fixed which is contrary to the basic principles of the respect of the private life from the conception especially as they are defined by an authority which the user does not know. The content of a CV certificate is very difficult to interpret because it contains a specific field called Certificate Holder Authorization Template (CHAT) which contains an object identifier and a sequence of bits that depends on this identifier. The way in which this microcircuit card is implemented, however, makes it possible to prevent the transfer of a quality from the person who owns it to a person who does not have it at the cost of deploying a very heavy architecture and very strict protocols. complex.

Further details were provided during a presentation made during the safety workshop held by ETSI in Sophia Antipolis on 24 June 2015 under the title: "elD and the principle of privacy by design".

The presentation is available on the ETSI website at the following address: http://docbox.etsi.org/Workshop/2015/201506_SECURITYWEEK/ elDAS_THREAD / S03_elD / DPSECURITYCONSULTING_PINKAS.pdf Summary of the invention The goal is to provide a simpler method for securing access to a server without any certified personal attribute being transferred from a person who owns it to a person who does not have it. The invention enables the deployment of Attribute Based Credentials (ABC) solutions that were under study in the ISO SC 27 WG 5 Committee in September 2015.

Thus, in the context of this invention, it is imperative to use a secure microcircuit, such as that which can be found in a "smart card" ("smart card" in English). Such a secure microcircuit will have to be implemented either by a natural person, or by a legal person or by a computer entity called "client application" (abbreviation CA), in the paradigm "client" -server".

This "client application" can also be a trusted applet operating in a browser, for example a Java applet.

The term "secure microcircuit" will be used hereinafter for convenience to denote any secure physical component capable of withstanding physical and logical attacks and capable of performing a set of functions implementing both protected internal data and data. external data provided by the microcircuit environment according to specific requirements. This term also covers the Trusted Platform Module (TPM) type components found in some professional computers and the Universal Integrated Circuit Card (UICC) standardized by 3GPP (3rd Generation Mobile System) and ETSI (European Telecommunications Standards Institute). ). The last term "fashionable" in English is now "secure element". His French translation "secure element" is however still little used. The invention is based on the concepts defined in the Fast Identity On-Line (FIDO) technical specifications which are available at the following address: https://fidoalliance.org/specifications/download

More exactly on the protocols described in the Universal Authentication Framework (UAF). The protocols described in this specification allow authentication using nicknames by using a different nickname for each server. Only the protocols described in the FIDO documents do not provide for and do not allow the presentation of certified attributes. The invention makes it possible to extend the architecture of FIDO and FIDO protocols to allow the transfer of certified attributes to a server while respecting the principle of respect for privacy from the moment of conception ("privacy by design" in English). ).

Several embodiments of the invention will be described below, by way of nonlimiting examples, with reference to the accompanying drawings in which: - Figure 1 schematically illustrates the original FIDO architecture, - Figure 2 illustrates schematically the completed FIDO architecture according to the invention, and - Figure 3 illustrates the essential data contained in a secure microcircuit according to the invention. The invention is a method making it possible, from a client application (10), to access an online server (11) ("Service Provider" in English, abbreviation SP) by means of a secure microcircuit (12). ), a pseudonym and a security token containing attributes, said token having been obtained from a server generating tokens (13), abbreviation SPJ, characterized in that the client application (10) is in the impossibility of being able to grant the benefit of said security token to another client application, and that the method comprises the following steps: - the provision of users by manufacturers of microcircuits of secure microcircuits with particular characteristics, - the creation an account on a target server by means of a pseudonym and such a secure microcircuit, - the creation of an account on a server generating tokens by means of a pseudonym and such a secure microcircuit, - the D requesting a security token from a server generating tokens by means of a pseudonym and such a secure microcircuit, - the generation of a security token by the server generating tokens, - the acceptance of the security token by the target server. The invention is characterized in that each secure microcircuit object of the method is delivered by its supplier with: - on the one hand, a Public Information (14) (abbreviation IP) contained in the secure microcircuit to know or deduce that the granting of said public information has been conditioned by the respect of the security requirements and functionalities applicable to the secure microcircuit and described in the context of said invention, and - on the other hand, a private key (15) (abbreviation CP) associated which will be used imperatively to perform certain specific operations, so that the digital signatures made using said private key are verifiable from said public information, and where the Public Information (14) contains at least information to know , through a contact to a server, if a public data specific to the secure microcircuit is to still valid (whitelist operation) or has been disabled (blacklisted operation).

According to a preferred embodiment, each secure microcircuit (12) is delivered by its supplier with: a public key certificate, and an associated private key, where the private key and the public key constitute a single pair, and where the certificate public key which constitutes the Public Information (14) contains at least one piece of information making it possible to know, by means of a contact to a server, whether a public datum specific to the secure microcircuit is still valid (whitelist operation) or has been disabled (blacklisted).

According to another embodiment, each secure microcircuit (12) is delivered by its supplier with: - Public Information (14) containing a public data specific to the secure microcircuit, an identifier of the microcircuit supplier, and a public key common to a set of microcircuits produced by said microcircuit supplier, and - a private key (15) specific to the microcircuit, calculated by said microcircuit supplier from a single private key kept secret by said microcircuit supplier, and where the information Public (14) contains at least one piece of information making it possible to know, through a contact to a server, whether a public datum specific to the secure microcircuit is still valid (whitelist operation) or has been invalidated (list operation black). The invention is characterized in that the secure microcircuit (12) generates, at the request of the client application, the data making it possible to implement the creation of an account on a given service provider or on a given server generating chips. by means of a pseudonym, the request of the client application being accompanied by at least the following parameter: an identifier IdS of the server object of the request, whereas in return, and if the identifier provided by the client application is not already present in the secure microcircuit, said microcircuit: - generates a pseudonym Ps, which is a random value of sufficient size with respect to the number of potentially authenticatable users on the server so that the probability that it can exist a collision between pseudonyms is almost zero, and - generates a bi-key (ie a pair of keys, ie a private key and a public key), then, after the user's agreement legitimate partner of the secure microcircuit (12), provides data enabling authentication with respect to the target server by digitally signing, using the private key generated above, at least the following data: (a) the pseudonym generated by the secure microcircuit for this server, (b) the value of the public key generates the secure microcircuit for this server, and stores in an entry (16) of the secure microcircuit the following information: the identifier of the server IdS (17), the pseudonym generated Ps (18) randomly for this server, the private key Cp (19) corresponding to the bi-key previously generated by the secure microcircuit (12) for this server, and is also able to store, associated with each entry, in a non-restrictive or exhaustive manner other information (20) such as: a date of creation of said entry (if it is provided by the client application), - a last date use of said input (if provided by the client application). The invention is characterized in that the secure microcircuit (12) provides, at the request of the client application (10), the data making it possible to implement the creation of an account on a given server generating chips by means of a pseudonym (18), while at the same time providing the server with the proof that a secure microcircuit (12) conforming to the requirements described in the context of the present invention is used, the application of the client application being accompanied at least by the following parameter: an identifier of the server generating tokens object of the request, while in return, and if the identifier provided by the client application is not already present in the secure microcircuit, said microcircuit: - generates a pseudonym (18 ), which is a random value of sufficient size with respect to the number of potentially authenticatable users on the server for the probability that there may be a collision between pseudonyms t almost zero, and - generates a double-key (i.e. a pair of keys: one private and the other public), then, after the agreement of the legitimate user of the secure microcircuit, provides data allowing the authentication with respect to the target server by providing and digitally signing using the private key (19) generated above at least the following data: (a) the pseudonym (18) generated by the secure microcircuit (12) for this server generating tokens, (b) the value of the public key generates the secure microcircuit for this chip-producing server, and by placing this digital signature in a field (c), and in addition by digitally signing using the private key specific to the secure microcircuit (15): the preceding digital signature presents in the field (c) or the data (a) and (b), as well as the public information (14) specific to the secure microcircuit, which is placed in a field (d), and places this second digital signature in a field (e), and stores in an entry (16) the following information: - an identifier of the chip producer server (17), - the randomly generated pseudonym (18) for this token generating server, - the private key ( 19) corresponding to the bi-key previously generated by the secure microcircuit for this server generating tokens, and - optionally, an indicator specifying that the entry was created according to this procedure No. 2 to the extent that the calling application does not does not wish to memorize this indicator, and is also able to memorize, associated with each entry, in a non-restrictive or exhaustive manner: a date of creation of said entry (if this one is provided by the client application), a date of last use of said entry (if it is provided by the client application), it being understood that said procedure n ° 2 must not under any circumstances be used by the client application with respect to a provider service (11). The invention is characterized in that a request for a security token addressed to the secure microcircuit (12) by the calling application (10) for a server generating tokens performed according to the procedure No. 3 described below, can be generated by the secure microcircuit (12) only when there are already at least two entries (16) in the secure microcircuit, the first designating a target server, ie the server for which the token is intended, the second designating a token-producing server whose input has been created according to the procedure n ° 2, and in this case, the client application (10) must provide to the secure microcircuit the following elements (a) a challenge or a unique number, in order to detect replay cases, (b) the types of attributes and / or attribute values that the client application wishes to be embedded in the security token, (c) a period of validity of attributes (for a multi-session token) or an empty or absent field (for a single session token), (d) a series of bytes representative of the target server, (e) a pointer relating to an entry located in the secure microcircuit designating designating the target server, (f) a pointer relative to an entry in the secure microcircuit designating the chip-producing server, while in return, the secure microcircuit, after the agreement of the legitimate user of the secure microcircuit, produces a formatted message that includes: (a) challenge or unique number, (b) attributes requested by the user, (c) attribute validity period (for multi-session token), or empty or missing field (for a single-session token), (d) the representative byte sequence of the target server, (e) the alias contained in the entry pointed to by the parameter (e) of the command, (f) the alias contained in the input pointed by the parameter (f) of the co mmande, (g) a digital signature applied to all of the preceding data, by means of the private key relating to the server generating tokens. The invention is characterized in that a request for a security token addressed to the secure microcircuit (12) by the calling application (10) for a server generating chips (13), performed according to the procedure No. 4 described below, can be generated by the secure microcircuit (12) only when there are already at least two entries (16) in the secure microcircuit, the first designating a target server, c ' that is, the server for which the token is intended, the second designating a token-producing server whose input has not been created according to procedure 2, and in this case the client application (10) must provide the secure microcircuit with the following: (a) a challenge or a unique number, in order to detect replay cases, (b) the types of attributes and / or attribute values that the client application wishes to see incorporated into the security token, (c) a period of validity of the attributes (for a multi-session token) or an empty or absent field (for a single-session token), (d) a sequence of bytes representative of the target server, (e) a pointer relating to an entry located in the microcircuit the target server, (f) a pointer relative to an entry in the secure microcircuit designating the server generating tokens, while in return, the secure microcircuit (12), after the agreement of the legitimate user of the secure microcircuit, produces a formatted message that includes: (a) the challenge or unique number, (b) the attributes requested by the user, (c) a validity period of the attributes (for a multi-session token) or a field empty or absent (for a single session token), (d) the representative byte sequence of the target server, (e) the pseudonym contained in the entry pointed to by the parameter (e) of the command, (f) the pseudonym contained in the input pointed by parameter (f) of the command, (g) a digital signature applied to all the preceding data, by means of the private key relating to the server generating tokens, (h) the public information specific to the secure microcircuit, (i) a digital signature applied on all previous data, using the private key specific to the secure microcircuit. The invention is characterized in that the secure microcircuit (12) formats each field of its signed responses unambiguously and that the data used to carry out this formatting are themselves signed data so that no operation may, from a functional point of view, be confused with another operation and therefore each of them may be unambiguously identified and the values used for that identification are part of the signed data, and if additional operations were to be implemented by the secure microcircuit, in any case a response to any of these additional operations, from the moment it is signed, should not be confused with another signed response and especially with the signed responses of the secure microcircuit following token requests as made by means of The invention is characterized in that a security token issued by a token-generating server (13) following a signed request from a secure microcircuit (12) comprises, to designate the owner of the token, a field containing the pseudonym of an already known owner of the target server and that, because of the process leading to its incorporation into the token, this pseudonym can only have been generated by a secure microcircuit (12 ) by means of a pseudo-random generator and that consequently its value can not have been freely chosen by anyone. The invention is characterized in that a security token issued by a token-generating server (13), following a signed request from a secure microcircuit (12), comprises to designate the target server to which the token is intended, a sequence of bytes that is not interpretable by the chip producer server (13), because this sequence of bytes is first locally calculated by the client application (10) using a hash function and two input parameters: a value of salage ("know value") and an identifier of the target server, then communicated to the chip-producing server as a parameter of the request to be incorporated in the token and accordingly when I client application communicates with the target server concomitantly with the token, this identifier and this value of salting, the latter can, thanks to these two values, recognize and combine these two values using the hash function to find the representative byte sequence present in the token so that the target server can verify that the security token is actually intended for it. The invention is characterized in that the agreement of the legitimate user of the secure microcircuit is obtained: (a) by the presentation of a PIN (Personal Identification Number) code by the legitimate owner of the secure microcircuit which is necessary for allow certain operations related to identification or authentication; this PIN code being called in this case an "elD-PIN", (b) by the comparison by the secure microcircuit of a biometric data specific to the legitimate user of the secure microcircuit which is necessary to authorize certain operations related to the (c) by a combination of an elD-PIN and a biometric data specific to the legitimate user of the secure microcircuit. The invention is characterized in that the secure microcircuit used in the context of the method must have the usual properties of a "security module" ("security module" in English) or a secure element ("secure element" in English) in the sense of the rules of the art, and in particular, resistance to external physical attacks, resistance to differential cryptographic attacks, the impossibility of duplicating the contents of the secure microcircuit if it does not allow it , and in addition, must contain the data described above, must support the procedure n ° 1, must support the procedure n ° 3 if it supports the procedure n ° 2, must support the procedure n ° 4 if it supports the procedure 2 and must comply with the requirements specified in the previous paragraph. The invention is characterized in that a chip-producing server (13) will not accept issuing a security token following a token request for a user identified under a given pseudonym that if he is able to verify that: (1) it is not the replay of a token request, either by checking that the challenge matches the one that was sent, or by checking that the unique number is in the allowed time range and that this unique number does not already exist among the unique numbers stored during this time range, (2) the pseudonym designating the token-producing server in the token request is known to it, (3) the account attached to that pseudonym n is neither temporarily nor permanently invalidated, (4) the token request is actually signed by the private key associated with the account, (5) the public information corresponding to the private key of the secure microcircuit that was implemented during the l opening of the account or at the latest when the request for the token is still valid or is neither expired nor revoked, (6) the public information has been issued by a trusted authority that issues such a information that after making sure that the secure microcircuit meets a specific specification to know that all security requirements applicable to secure microcircuit are respected. The invention is characterized in that a target server will agree to associate, after the usual checks, to an account opened under a pseudonym the attributes contained in a security token, only if an account has already been opened on this server under the alias contained in the ad-hoc field of the security token, only if this account is neither temporarily nor permanently invalidated, than if the date on which the token was issued is close to the present time or well if a validity period is indicated in the token, if the present time is included in this period of validity, only if the target server recognizes itself as a recipient of the token and if the security token has been signed by a server token producer known to the target server to perform all the checks prescribed in the preceding paragraph.

As illustrated in Figure 1, the FIDO architecture includes a client application (10) and a service provider (11). An account must be systematically created on the server of the service provider, before any access.

While FIDO allows several variants and does not impose the use of microcircuits, the invention requires the use of microcircuits and in particular the following two requirements: a) the pseudonym used on a service provider (11) can not be generated by a secure microcircuit (12) respecting all the criteria defined in the method, and b) the authentication key pair associated with this pseudonym for this service provider (11) can only be generated by a secure microcircuit (12) respecting all the criteria defined in the process.

In this way, neither the user nor the service provider (11) has the possibility to choose the pseudonym that will be used on a service provider (11), nor to have knowledge of the associated private key to this pseudonym and to this service provider (11), since the latter resides exclusively in the secure microcircuit (12). If the user has the use of the private key, he does not have the knowledge of the value of the private key.

As illustrated in FIG. 2, in a structure according to the invention, the initial architecture of FIDO is extended by adding two components: 1) an attribute provider (21) ("Attribute Provider" in English), and 2) an identity provider (22) ("Identity Provider").

The term "chip producer server" (13) will be used to designate either an identity provider (22) or an attribute provider (21).

In the example shown, only one identity provider, one attribute provider, and one service provider are represented. However, for the same client application, there may be several servers for each type.

An identity provider (22), just like an attribute provider (21), is able to issue security tokens ("security tokens"). A security token is a bitstream or bytestream that is digitally signed by an identity provider (22) or an attribute provider (21) and which includes one or more attributes relating to a person (or to an entity).

These attributes are said to be "certified" by the identity provider (22) or the attribute provider (21).

The difference between an identity provider (22) and an attribute provider (21) depends essentially on the nature of the attributes that are delivered.

An identity provider (22) mainly delivers attributes of the type: last name, first name, date of birth, place of birth, all this information having been generally collected and verified either from national identity documents in paper form, or from national identity documents in electronic form.

An attribute provider (21) can issue any type of attribute, namely identity attributes and / or attributes, for example of the type: "Member of the golf club of Saint-Nom-la-Bretèche" or well "Graduate of a DEA of Physics from the University of Paris VI, Option" Theory of games ", but also attributes of the type name, first name, date of birth, place of birth, place of residence, etc.

An attribute provider (21) may, in some cases, require the presentation of a security token issued by an identity provider (22) before accepting to issue a security token.

Figure 1 indicates a dialogue D1 (23) between the client application (10) and the service provider (11),

Figure 2 mentions three types of dialogs: - a dialogue D1 (23) between the client application (10) and the service provider 11, - a dialogue D2 (24) between the client application (10) and the provider of attributes (21), and - a dialogue D3 (25) between the client application (10) and the identity provider (22),

According to the three cases (A, B and C) described below, two or three dialogues are implemented.

Case A. The client application (10) directly contacts the attribute provider (21) by means of the dialogue D2 (24) in order to obtain a security token, then contacts the service provider (11) by means of the dialogue D1 (23) in order to transmit it to him.

Case B. The client application (10) directly contacts the identity provider (22) by means of the dialogue D3 (25) to obtain a security token, then contacts the service provider (11) by means of the dialogue D1 (23) in order to transmit it to him.

Case C. The client application 10) first contacts the identity provider (22) by means of the dialogue D3 (25) in order to obtain a security token, then contacts the attribute provider (21) with the the dialogue D2 (24) to transmit it to him, receives back another security token and finally contacts the service provider (11) by means of the dialogue D1 (23) to transmit the second security token.

The remainder of the document will use the expression "target server" to designate a server to which a token is intended. A target server will usually be a service provider (10), but may also be an attribute provider (21) when a security token from an identity provider is presented to it.

In the illustrated example, the exchanges for these three dialogs will preferably be performed in HTTPS (or equivalent) mode so that the content of the exchanges is not understandable to the outside world and that any modification or replay of an exchange can be detected. .

Before being able to request a token from a token-generating server, the client application (10) must first create an account on this chip-producing server using the secure microcircuit (12).

Before being able to present a token to a target server, the client application (10) must first create an account on the target server using the secure microcircuit (12).

The creation of these accounts should preferably be done through a link in HTTPS mode (or equivalent) so that the client application located on the workstation of the user can be sure to be in contact with the "good server". The client application (10) can then apply to a server generating tokens to obtain a security token (13) which will contain one or more attributes and which will then be presented to a target server. Depending on the attributes contained in the token, the access will then be authorized or not by the target server. The invention imposes the following Rule 1 on the chip-producing servers: a chip-producing server (13) will only accept to issue a security token to a user if it is able to obtain the assurance that the security token that has been requested has been requested by a user who uses a secure microcircuit (12) that has characteristics that are the subject of the process. The invention imposes the following Rule 2 on target servers: a target server will only accept a security token from a token-producing server (13) if it is able to obtain assurance that the security token that has been generated by this token-generating server (13) has been only following the request of a user who uses a secure microcircuit (12) that has all the features that are the subject of the process .

In the examples illustrated in FIGS. 2 and 3, the device is an ICC (Integrated Circuit Card) microcircuit card. The creation of an account on a server generating tokens (13) is a prerequisite, it is sufficient to prove once and only once to such a server that a secure microcircuit that has all the characteristics that are the subject of the method is implemented by the known user of the chip producer server (13) under a given pseudonym. Optimally, the demonstration of the implementation of a secure microcircuit having all the characteristics required by the method will thus be performed during the creation of the account on the chip producer server (13). However, this can also be done during the first request for security token, or again, at each request for security token (which would then be not optimum, but technically possible).

Thus, no security token will be issued by a server generating tokens (13), if the user is not able to demonstrate when creating the account, or failing at the time of the first token request or else failing at each request for token that it uses a physical device that has on the one hand all the general characteristics of a secure microcircuit, in particular: resistance to external physical attacks, resistance to differential cryptographic attacks, impossibility of duplicate the contents of a microcircuit if the microcircuit does not allow access to certain contents; and on the other hand complementary particular characteristics, essential to the proper functioning of the process. These will be detailed below.

The fact that the user uses a given secure microcircuit (for example, identifiable by a serial number) must be demonstrated to a server generating tokens (13), but especially not to a service provider (11).

Indeed, if such a demonstration were made, it could reveal a specific identifier to secure microcircuit, which could allow service providers to establish links between their users, which is contrary to one of the principles of compliance with private life.

The service provider (11) will obtain indirect insurance because the user who actually uses a secure microcircuit that has all the features that are the subject of the process. Indeed, the service provider (11) will trust only the chip-producing servers (13) that guarantee it perform this verification.

Each secure microcircuit (12) must comprise: - public information (14), to verify the signed data with the private key specific to the microcircuit, and - a private key (15) of its own.

This is illustrated in Figure 3. The public information allows to know directly or indirectly that its granting was conditioned by the assurance that the secure microcircuit (12) meets the requirements imposed on the microcircuit because of the method, for example, in issuing a public key certificate under a given Certification Policy (PC).

A secure microcircuit (12) conforming to the requirements of the process should preferably be certified by an independent body according to a set of requirements established in the form of a Protection Profile (PP) and with a level of assurance " high ", for example" EAL4 + ". The result of the certification may be given to the manufacturer of the microcircuit who can then avail.

Each microcircuit manufacturer producing secure microcircuits conforming to the requirements of the process must ensure that the Public Information (14) contained in the secure microcircuit (12) contains at least one information allowing to know, by means of a contact at a server, if a public data specific to the secure microcircuit is still valid or has been invalidated.

When opening an account on a service provider (11) or on a server generating tokens (13), the secure microcircuit (12) must be able to generate two data and associate them with an identifier of IdS server (17), as illustrated in Figure 3: - a pseudonym Ps (18), which is a random value of sufficient size to avoid any collision between pseudonyms on the server in question and which must imperatively be generated by the microcircuit, and, a bi-key (ie a pair of keys: ie a private key Cp (19) and a public key) which must imperatively be generated by the microcircuit. Since the user wants to have more than one account on the same server, an index can be added.

The above elements are then implemented to perform an authentication and once it is successful, the microcircuit permanently stores at the level of an "entry" (16), at least, the following three pieces of information: identifier of the remote server IdS (17), the pseudonym Ps (18) randomly generated for this remote server, - the private key Cp (19) corresponding to the bi-key generated previously for this remote server by the microcircuit. Other information (20) can be added. In particular, to better manage the obsolescence and deletion of entries that are no longer used, each entry may further include: - the date of creation of the entry, and / or - the date of the last use of the 'Entrance.

In order to optimize the operation, the client application (10) can request that the private key (15) specific to the secure microcircuit (12) as well as the public information (14) for verifying the data signed with the private key ( 15) specific to this secure microcircuit (12) is implemented during authentication. If this is the case, this feature can be memorized by the secure microcircuit (12) so that the client application (10) can take into account and avoid repeating the same request during another authentication.

Naturally, the client application has a command allowing, after the agreement of the user, the deletion of one or more entries (16).

In order to optimize the management of the inputs (16), the client application may also have an interest in providing the microcircuit with a complementary indicator enabling it to differentiate between an entry relating to a service provider (11) and a relative entry. to a server producing tokens (13). If this is the case, the indicator will be memorized by the secure microcircuit (12) in the input (16) as complementary data (20) in question.

We will now examine the structure of a security token.

According to the method of the invention, a security token issued by a server generating tokens and intended for a target server will comprise at least the following information: (a) the beneficiary of the token, in the form of a pseudonym of the as known to the target server, (b) one or more attributes of the user, (c) an unambiguous identifier of the token-producing server, for example, an X.509-type certificate, (d ) for a multi-session token, a validity period of the security token possibly associated with a field making it possible to check the revocation status of this token; or, for a single-session token, the time the token was issued, usually a Universal Coordinated Time (UTC), (e) a unique token identification number assigned by the token-producing server, (f) the target server to which the token is intended, in the form of a sequence of bytes allowing only the target server to recognize itself, (g) a digital signature of the previous values using the private key of the server generating the chips.

Field (a) allows the target server to know which nickname the token was generated for. If the nickname is not recognized, the security token must be rejected by the target server.

Field (b) allows the target server to know the certified attributes as issued by an identity server (22) or by an attribute server (21).

Field (c) ensures the identity of the signer of the security token.

Field (d) is used to issue single-session or multi-session security tokens. Thus: - For a single session security token, the attributes present in the token will only be retained by the service provider (11) during a single login. Any session has a limited duration, with a timeout period ("time-out") in case of prolonged inactivity. - For a multi-session security token, the attributes present in the token will be retained by the service provider (11) for a validity period defined in the token. If this validity period is considered to be "long enough" by the identity server (22) or by the attribute server (21), the latter may implement a revocation mechanism that will make it possible to revoke all the attributes contained in the token.

The field (e) makes it possible to identify the security token number for the purpose of revoking it, for example using a mechanism of the CRL (Certificate Revocation List) type or the OCSP (On-line Certificate) type. Status Protocol). The field (e) also makes it possible to uniquely identify, in particular for auditing purposes, a token issued by a server generating tokens.

The field (f) makes it possible to target the security token for a given target server, without allowing the identification of this server by the server generating tokens. To do this, before requesting a token to a server generating tokens, the user will hide the target server identifier in the following manner.

It combines by means of a non-invertible compression function, sometimes called "hash function", the identifier of the target server with a random value, called "salting value" (knows value). The result of the calculation is placed in the field (f) entitled "representative byte sequence of the target server". The identifier of a target server having semantics is therefore never present in the security token and the identifier or the identity of the target server thus remains totally unknown to the server generating the token. In particular, the identifier or the identity of an attribute server (21) remains totally unknown to an identity server (22). This is an advantageous feature of the process.

However, it is necessary for the target server to know that the security token is intended for it. For this purpose, the client application communicates to the target server the salting value while a fixed rule is defined to transform the address of the target server into a target server identifier. Thus, the target server knowing both the salting value and its own identifier is able to verify that the value contained in the field (f) is that it has recalculated locally. If this is not the case, the token must be rejected. For the creation of an account on a server generating tokens, the user transmits to the microcircuit: - an identifier of the server producing tokens.

In return, the microcircuit produces a formatted message that comprises: (a) the pseudonym generated by the microcircuit for this server, (b) the value of the public key generated by the microcircuit for this server, (c) a digital signature on the three previous data, calculated by means of the private key generated by the microcircuit for this server, (d) public information, such as a public key certificate, for example of the X.509 type, making it possible to check the data signed with the key private specific to this microcircuit, and (e) a digital signature on all previous data by means of the private key specific to the microcircuit.

Note 1: the field (d) could also be part of the data signed by the private key generated by the microcircuit for this server, but for strictly security reasons this is not essential.

Note 2: A digital signature is usually calculated using a private key on a hash value computed using a one-way hash function, supplemented where appropriate by padding bits (in English).

The field (c) makes it possible to prove the possession of the public key contained in the field (b).

The field (e) allows the server generating tokens to ensure using the field (d) that the received data come from a microcircuit conforming to the requirements of the process and that it is this certificate that belongs to the microcircuit. Once these checks have been made, the token generating server creates an account associated with the pseudonym and the public key that have been generated by the microcircuit.

Note 3: Fields (d) and (e) may additionally be considered as protection against unwanted account openings, as only a microcircuit holder that complies with the process requirements will be able to open an account on a server chip producer.

If the response of the chip producer to the account creation request is positive, then the user must confirm that he agrees to create a new entry in his microcircuit by presenting an elD-PIN. Otherwise, the data that was temporarily stored in the memory of the microcircuit would be erased.

For the creation of an account on a service provider (11), the user transmits to the microcircuit: - the identifier of the service provider (11).

In return, the microcircuit produces a formatted message that comprises: (a) the pseudonym generated by the microcircuit for this server, (b) the value of the public key generated by the microcircuit for this server, (c) a digital signature on the three previous data generated by means of the private key associated with this server.

It will be observed that the parameters (d) and (e) that were previously present for the creation of an account on a server generating tokens, do not appear in the list above. This is wisely. Indeed, if they were present, this would allow service provider servers (11) to establish links between their respective accounts.

If the response of a service provider (11) to the request for creation of the account is positive, then the user will have to confirm that he agrees to create a new entry in his microcircuit, for example by presenting an elD -PINE.

An elD-PIN (Electronic Identification - Personal Identification Number) is a PIN (Personal Identification Number) specific to electronic identity functions to be implemented. It is known to the legitimate owner of the microcircuit and must be presented to the microcircuit to allow the execution of certain functions or commands of the microcircuit related to authentication. Indeed, there may exist another PIN on the same microcircuit to allow the execution of certain functions or circuit commands related to the electronic signature. If the elD-PIN has already been presented, and it is undesirable for ergonomic reasons to ask the user to provide "n times" his elD-PIN in a short period of time, the application client can request confirmation by means of a human-machine interaction and present the elD-PIN to the microcircuit transparently for the user. Those skilled in the art will certainly have noticed the absence of the use of a mechanism for detecting the replay of the account creation request. In the circumstances, for a request to create an account, the use of such a mechanism is not necessary, since a pseudonym (whether or not it has been generated by a microcircuit) will be refused if an account has already been successfully opened under this alias on the server.

However, and usually, in any data exchange of the request / response type between a client and a server, it is necessary to set up a mechanism for detecting the replay of a request or a request. reply. Two techniques exist to perform such protection: the use of challenges ("challenges" in English) or the use of unique numbers ("unique numbers" in English). The use of the challenges requires a minimum of four exchanges, whereas the use of the unique numbers requires only two exchanges, with in return the use of clocks weakly synchronized with respect to the Universal Coordinated Time (UTC): for example, of the order of ten minutes. This is easy to obtain with current technology. Details are available in the ISO / IEC 10181-2: 1996 standard. Information technology - Open Systems

Interconnection - Security frameworks for open Systems: Authentication framework.

However, for operations that concern already open accounts such a replay detection mechanism is necessary. The operations that are described below make it possible to use both the challenge technique and the unique number technique. In the first case, the challenge received during the second exchange is incorporated into the data conveyed during the third exchange, whereas in the second case, the unique number is directly incorporated into the data conveyed during the first exchange. The challenge or the unique number must always be transmitted by the client application to the microcircuit.

For authentication with a server using a pseudonym, the user transmits to the microcircuit the following elements: (a) a challenge or a unique number, according to the chosen replay technique, (b) the identifier of the remote server.

In return, the microcircuit produces a formatted message that includes: (a) the challenge or unique number, (b) the user's pseudonym for that entry, (c) a digital signature applied to the two data above in using the private key associated with this entry.

Note: In the case of authentication with a token producer, the lifetime of the microcircuit certificate may lead to the addition of two additional protocol elements, provided that: (i) the microcircuit certificate is renewable, and (ii) such a renewal would not result in a period of validity of the certificate exceeding the life of the microcircuit itself.

The two complementary protocol elements are then as follows: (d) the new certificate, for example of the X.509 type, comprising the public key specific to the microcircuit, and (e) a digital signature on all the preceding data by means of the private key specific to the microcircuit. The user will then have two possibilities: - send his messages directly via the HTTPS protocol (or in the absence of HTTP), or - allow the authentication of his messages by having them signed by the microcircuit by means of the private key associated with this server and that the protocol used is the HTTP protocol or the HTTPS protocol.

The choice will be made by the user depending on the volume of data to be exchanged and / or the importance of the semantics of these data.

For authentication of messages to a server using a pseudonym, the user transmits to the microcircuit the following elements: (a) a challenge or a unique number, according to the selected replay technique, (b) the identifier of the remote server, (c) the content of the message to be authenticated.

In return, the microcircuit produces a formatted message that includes: (a) the challenge or unique number, (b) the user's pseudonym for that entry, (c) the message content that is the subject of the message. authentication (data origin authentication), (d) a digital signature applied to the three preceding data using the private key associated with this entry.

Note: While the HTTPS protocol ensures both the integrity and the confidentiality of the data conveyed between a client and a server, the transmitted message makes it possible to authenticate the origin of the message and the fact that this message has passed through the microcircuit of the user holding the pseudonym.

To allow the generation of the message formatted by the microcircuit, the user will have to indicate to the microcircuit that he agrees to authenticate, for example, by presenting an elD-PIN.

It is now useful to describe how to generate a token request by a microcircuit so that the generation request produced by the microcircuit can then be transmitted by the client application to a server generating tokens.

For the generation of a token request addressed to the secure microcircuit, the user transmits to the secure microcircuit the following elements: (a) a challenge or a unique number, (b) the types of attributes and / or the types and values of attributes that the client application wants to be embedded in the security token, (c) a validity period of attributes (for a multi-session token) or an empty or absent field (for a single-session token), (d) a continuation bytes representative of the target server, (e) a pointer relating to an input located in the microcircuit designating the target server, (f) a pointer relating to an input located in the microcircuit designating the server generating tokens.

Field (a) provides protection against replay. It should be noted that this protection is complementary to that offered by the HTTPS protocol, if it is implemented.

Field (b) allows the client application A, following a dialogue with the user, to request only the attributes that the user wishes to see embedded in the token. It is a combination of two privacy principles known as "data minimization" and "user consent". ("user consent" in English).

Field (c) is used to issue single-session or multi-session security tokens.

Field (d) is "copied and pasted" into the security token by the token-producing server.

Field (e) is essential because it allows to select the pseudonym of the user that will be incorporated into the security token. It is particularly important to note that this pseudonym must already be present in the secure microcircuit and that it has therefore necessarily been generated by the secure microcircuit and that therefore it can not be any case the pseudonym used by another person with whom the token applicant would collude. It is this fundamental characteristic that prevents the transmission of an attribute belonging to a person (or entity) to the benefit of one or more other persons (or entities), even if those persons (or entities) are of connivance.

The field (f) has two uses: (i) it makes it possible to indicate the pseudonym of the user as it is already known to the server generating tokens and which will be contained in the request of the security token that will be generated by the microcircuit, and (ii) it selects the private key associated with the chip-producing server and which will be used by the microcircuit to sign the token request.

In return, the secure microcircuit produces a formatted message that includes: (a) the challenge or unique number, (b) the attributes requested by the user, (c) a validity period of the attributes (for a multi-session token) or an empty or absent field (for a single-session token), (d) the representative byte sequence of the target server, (e) the pseudonym used by the user on the target server, (f) the pseudonym used by the the user on the token-producing server to which the security token will be requested, (g) a digital signature applied to all of the preceding data, by means of the private key relating to the server generating tokens.

By checking the field (a), the chip-producing server can make sure that the command received is not the replay of a previously sent command.

By using the field (b), the server can incorporate the requested attributes, obviously to the extent that the user actually has them. The user has the possibility to request each attribute either by indicating only its type, or by indicating both its type and a value.

By using field (c), the server can generate a multi-session token or a single-session token, as long as it supports both types of tokens.

The value contained in the field (d) is copied blind from the field (d) of the command. This same field will subsequently be copied blindly in the field (f) of the security token by the server generating tokens. In this way, a server producing tokens can not identify the consumer servers of the token, by simply examining the orders received.

The value contained in the field (e) is the pseudonym that comes from the value contained in the secure microcircuit in the input pointed in the field (e) of the command.

Field (f) will allow the token-producing server to select the appropriate public key to enable it to verify the digital signature contained in field (g).

Before issuing a security token, the chip producer must verify that the secure microcircuit certificate attached to the account is not revoked. If this certificate has been revoked, then the requested token must not be issued.

It is essential that the field (e) above actually come from the secure microcircuit and not from external data, otherwise it would be possible to change the beneficiary of the token as it sees fit. Out, there is a function to ensure the integrity and authentication of external data (not yet described at this stage of the presentation). It must therefore be ensured that the latter function can never be used to mimic a signed token request.

There are several ways to make it impossible to do such a masquerade. For example, by imposing the order in which the different parameters must be included in the response as well as an encoding for each parameter, for example of the type TLV (Type, Length, Value) or using tags of the XML type. The advantage of TLV encoding, such as the Basic Encoding Rules (BER) or the Distinguished Encoding Rules (DER) of ASN.1, is its compactness.

Another way to do this is to systematically insert at the head of the message (or at the tail of the message) a different code making it possible to differentiate between a response to a request for a security token request and any response to another command, in particular, a command to ensure the integrity and authentication of external data. From the moment when the coding of the fields or the additional data form part of the data which enters into the computation of the digital signature, then it is possible to discriminate between the different types of messages.

If a user wishes to present to a target server a security token that he has obtained from a server generating tokens, two variants are possible, in particular: (a) the security token can be transmitted after the authentication of the user by means of his pseudonym; the link between the message and the token is then achieved through the use of the HTTPS protocol, (b) the security token can be part of the content of a message that is subject to authentication ("data origin authentication" , in English); the link between the message and the token being then realized that there is or not the implementation of the HTTPS protocol.

Of course, the invention is not limited to the preferred embodiments which have just been described, but on the contrary the invention is defined by the following claims.

It will be apparent to those skilled in the art that various modifications can be made to the embodiments of the method described above, in the light of the teaching that has just been disclosed.

Description of the embodiments

The secure microcircuit will be realized by means of a single electronic component or by means of several electronic components encapsulated in another component or by means of several electronic components protected by a secure enclosure, generally called "cryptographic enclosure", one or the other of these embodiments having protections as described in the invention, while said "secure microcircuit" will interface with its external environment, either by means of an interface with contacts, or by means of an interface without touching.

Brief description of the drawings

Figure 1 schematically illustrates the original FIDO architecture.

Figure 2 schematically illustrates the FIDO architecture completed according to the invention.

Figure 3 illustrates the essential data contained in a secure microcircuit according to the invention.

List of abbreviations used ASN.1: Abstract Syntax Notation One. BER: Basic Encoding Rules. CEN: European Committee for Standardization. CHAT: Certificate Holder Authorization Template, ("Authorization Template for a Certificate Holder" in French). CRL: Certificate Revocation List ("CRL"). CV certificate: Card Verifiable certificate ("Certificate verifiable by a card" in French). DER: Distinguished Encoding Rules. EAL4: Evaluation Assurance Level 4 ("Level 4 Insurance Evaluation" in French). elD-PIN: Electronic Identification - Personal Identification Number ("personal identification number for electronic identification" in French). ETSI: European Telecommunications Standardization Institute ("European Telecommunication Standardization Institute" in French). FIDO: Fast Identity On line. ICC: Integrated Circuit Card ("microcircuit card" in French). HTTP: HyperText Transfer Protocol, ("Hypertext Transfer Protocol" in French). HTTPS: HyperText Transfer Protocol Secure, ("Secure Hypertext Transfer Protocol" in French). OCSP: "One-line Certificate Status Protocol". PC: Certification Policy ("Certification Policy"). PIN: Personal Identification Number ("Personal Identification Number" in French). PP: Protection Profile ("Protection Profile"). TLV: Type, Length, Value ("Type, Length, Value"). TPM: Trusted Platform Module. UAF: Universal Authentication Framework ("Universal Authentication Framework" in French). UTC: Universal Coordinated Time ("Coordinated Universal Time" in French). XML: Extensible Markup Language. X.509: ITU-T X.509 Recommendation: Open Systems Interconnection -The Directory: Public key and attribute certificate frameworks.

List of documents cited

- Application Interface for secure elements used as Qualified Electronic Signature (Seal-) Creation Devices "CEN Working Documents TC 224 WG 17:" Draft EN 419 212-1 to draft EN 419 212-5 ", only available to members of the CEN TC 224 WG 17 at the time of filing - ASN.1: Abstract Syntax Notation One ITU-T Recommendations X.680 to X.683 (ISO / IEC documents refer to 8824-1 to 8824-4) BER, CER and DER encodings are specified by X.690 - ISO / IEC 10181-2: 1996 Information technology - Open Systems Interconnection - Security frameworks for open Systems: Authentication framework - "elD and the principle of privacy by design. "Presentation made on June 24, 2015, available at the following address: http://docbox.etsi.org/Workshop/2015/201506_SECURITYWEEK/ elDAS_THREAD / S03_elD / DPSECURITYCONSULTING_PINKAS.pdf - FIDO Alliance Technical Specifications (Fast Identity On line), accessible at the following address: https : //fidoalliance.org/specifications/download - Universal Authentication Framework - UAF. FIDO Alliance, accessible at the following address: https://fidoalliance.org/specifications/download - Recommendation ITU-T X.509. Information technology - Open Systems Interconnection - The Directory:

Public key and attribute certificate frameworks.

Claims (15)

Claim 1. A method for accessing a target server online from a client application by means of a secure microcircuit, a pseudonym and a security token containing attributes, said token having obtained from a server generating tokens, which can be either an attribute provider or an identity provider, characterized in that the client application is unable to grant the benefit of said token to another client application, and that the method comprises the following steps: - the creation of an account on a target server or on a token-generating server by means of a pseudonym and a request generated by a secure microcircuit which provides , at the request of the client application, all the data allowing the creation of the account, - the creation of an account on a server producing tokens by means of a pseudonym and a request g generated by secure microcircuit which provides, at the request of the client application, the set of data allowing the creation of the account by means of a pseudonym and which makes it possible to demonstrate that a secure microcircuit manufactured by a microcircuit supplier according to a precise specifications are actually implemented to carry out this operation, - the request for a security token from a server generating chips being specified that the essential data to make this request must be generated by the secure microcircuit, - the generation of a security token following a signed token request from a secure microcircuit, comprising two characteristic fields, if, and only if, at the latest at the time of the token request, the server generating chips obtained the assurance that the token request came from a secure microcircuit manufactured by a microcircuit specific characteristics, - acceptance of the security token by the target server, if the target server recognizes itself as target server of the token, if the token is recognized as valid, if an account has been previously opened on the server target under the alias contained in the security token and if the security token was signed by a server generating tokens known to the target server for having obtained the assurance that the token request came from a chip manufactured by a supplier microcircuits according to precise characteristics. Claim 2. Method according to claim 1 characterized in that each secure microcircuit is delivered by its supplier with: - on the one hand, a public information contained in the secure microcircuit to know or deduce that the granting of said public information has been conditioned by the respect of the safety and functionality requirements applicable to the secure microcircuit and described in the context of said invention, and - on the other hand, an associated private key which will be used imperatively to perform certain specific operations, in such a way that digital signatures made using said private key are verifiable from said public information, and where the Public Information contains at least one piece of information allowing to know, through a contact to a server, whether a specific public data to secure microcircuit is still valid (whitelist operation) o u has been disabled (blacklisted). Claim 3. According to a preferred embodiment of claim 2 each secure microcircuit is delivered by its provider with: a public key certificate, and an associated private key, where the private key and the public key constitute a single asymmetric key pair, and where the public key certificate contains at least one piece of information making it possible to know, through a contact to a server, whether a public datum specific to the secure microcircuit is still valid (whitelist operation) or has been invalidated ( blacklist operation). Claim 4. According to another preferred embodiment of claim 2, each secure microcircuit is delivered by its supplier with: a Public Information containing, in particular, a public data specific to the secure microcircuit, an identifier of the microcircuit supplier, and a common public key to a set of microcircuits produced by said microcircuit supplier, and - a private key specific to the microcircuit, calculated by said microcircuit supplier from a single private key kept secret by said microcircuit supplier, and the Public Information contains at least one piece of information making it possible to know, by means of a contact to a server, whether a public datum specific to the secure microcircuit is still valid or has been invalidated. Claim 5. Method according to claims 1 and 2 characterized in that the secure microcircuit, according to the procedure No. 1 described below, generates at the request of the client application data to implement the creation of an account on a given service provider or on a given token-generating server, the application of the client application being accompanied by at least the following parameter: an identifier of the server that is the subject of the request, while return, and if the identifier provided by the client application is not already present in the secure microcircuit, said microcircuit: - generates a pseudonym, which is a random value of sufficient size with respect to the number of potentially authenticatable users on the server so that the probability that there may be a collision between pseudonyms is almost zero, and - generates a bi-key (ie a key pair, ie a key private and a public key), then, after the agreement of the legitimate user of the secure microcircuit, provides data allowing authentication with respect to the target server by digitally signing using the private key generated above at least the following data: (a) the pseudonym generated by the secure microcircuit for this server, (b) the value of the public key generated the secure microcircuit for this server, and stores in an entry the following information: - the identifier of the server, - the pseudonym randomly generated for this server, - the private key corresponding to the bi-key previously generated by the secure microcircuit for this server, and is also able to store, associated with each entry, in a non restrictive, not exhaustive: - a date of creation of the said entry (if this one is provided by the client application), - a date of last use of the said entry (if c it is provided by the client application). Claim 6. Method according to claims 1 and 2 characterized in that the secure microcircuit, according to the procedure No. 2 described below, provides at the request of the client application data to implement the creation of an account on a server generating tokens given by means of a pseudonym, while at the same time providing the server with the proof that a secure microcircuit conforming to the requirements described in the context of said invention is used, the application of the client application being accompanied by minimum of the following parameter: an identifier of the server generating tokens object of the request, while in return, and if the identifier provided by the client application is not already present in the secure microcircuit, said microcircuit: generates a pseudonym, which is a random value of sufficient size with respect to the number of potentially authenticatable users on the server for the probability that it there may be a collision between pseudonyms that is almost zero, and - generates a bi-key (i.e. a pair of keys: one private and the other public), then, after the agreement of the legitimate user of the secure microcircuit, provides data allowing the authentication with respect to the target server by providing and digitally signing using the private key generated above at least the following data: (a) the pseudonym generated by the secure microcircuit for this chip-producing server, (b) the value of the public key generated the secure microcircuit for this chip-producing server, and by placing this digital signature in a field (c), and moreover by digitally signing using the private key specific to the secure microcircuit: the previous digital signature present in the field (c) or data (a) and (b), as well as - the public information specific to the secure microcircuit, which is placed in a field (d), and places this second digital signature in a field (e), and stores in an entry the following information: - the identifier of the server generating tokens, - the pseudonym randomly generated for this server generating tokens, - the private key corresponding to the bi-key previously generated by the secure microcircuit for this server producer tokens, and, optionally, an indicator specifying that the entry was created according to this procedure No. 2 insofar as the calling application does not wish to memorize this indicator, and is also able to store, associated with each entry , in a non-restrictive or exhaustive manner: - a date of creation of the said entry (if this one is provided by the client application), - a date of last use of the said entry (if it is provided by the client application), it being understood that said procedure n ° 2 must not under any circumstances be used by the client application with respect to a service provider. Claim 7. Method according to claims 1,2, 5 and 6, characterized in that a request for a security token addressed to the secure microcircuit by the calling application for a server producing tokens performed according to the procedure n ° 3 described below, can be generated by the secure microcircuit only when there are already at least two entries in the secure microcircuit, the first designating a target server, that is to say the server for which the token is intended, the second designating a token-producing server whose entry was created according to the procedure n ° 2, and in this case, the client application must provide to the secure microcircuit the following elements: (a) a challenge or a unique number, in order to detect replay cases, (b) the types of attributes and / or attribute values that the client application wishes to be embedded in the security token, (c) a period of Validi attributes (for a multi-session token) or an empty or absent field (for a single-session token), (d) a sequence of bytes representative of the target server, (e) a pointer to an entry located in the microcircuit secure designating the target server, (f) a pointer to an entry in the secure microcircuit designating the chip producer server, while in return, the secure microcircuit, after the agreement of the legitimate user of the microcircuit secure, produces a formatted message that includes: (a) challenge or unique number, (b) user-requested attributes, (c) attribute validity period (for multi-session token), or empty field or absent (for a single session token), (d) the representative byte sequence of the target server, (e) the alias contained in the entry pointed to by the parameter (e) of the command, (f) the pseudonym contained in the input pointed by the parameter (f) of the command, (g) a digital signature applied to all the preceding data, by means of the private key relating to the server generating the token. Claim 8. Method according to claims 1,2, 5 and 6, characterized in that a request for a security token addressed to the secure microcircuit by the calling application for the purpose of a server generating tokens, performed according to the procedure No. 4 described below, can be generated by the secure microcircuit only when there are already at least two entries in the secure microcircuit, the first designating a target server, ie the server for which the token is intended, the second denoting a chip-producing server whose input has not been created according to the procedure n ° 2, and in this case, the client application must provide to the secure microcircuit the following elements: a) a challenge or a unique number, in order to detect replay cases, (b) the types of attributes and / or attribute values that the client application wishes to be embedded in the security token, (c ) a period of validity of the attributes (for a multi-session token) or an empty or absent field (for a single-session token), (d) a sequence of bytes representative of the target server, (e) a pointer relating to an entry located in the microcircuit secure designating the target server, (f) a pointer relating to an entry in the secure microcircuit designating the server generating chips, while in return, the secure microcircuit, after the agreement of the legitimate user of the secure microcircuit, produces a formatted message that includes: (a) challenge or unique number, (b) attributes requested by the user, (c) attribute validity period (for multi-session token), or empty or missing field (for a single-session token), (d) the representative byte sequence of the target server, (e) the alias contained in the entry pointed to by the parameter (e) of the command, (f) the alias contained in the input pointed by the parameter (f) of the ommand, (g) a digital signature applied to all of the preceding data, by means of the private key relating to the server generating tokens, (h) the public information specific to the secure microcircuit, (i) a digital signature applied to all previous data, using the private key specific to the secure microcircuit. Claim 9. A method according to claims 5, 6, 7 and 8 characterized in that the secure microcircuit formates each field of its signed responses unambiguously and the data used to perform this formatting themselves are part of the signed data of so that no operation can, from a functional point of view, be confused with another operation and that consequently each of them can be unambiguously identified and that the values used for this identification are part of signed data, and that if additional operations to operations described in these claims were to be implemented by the secure microcircuit, in no case a response to any of these additional operations, from the moment it is signed, does not should be confused with another signed answer and especially with the signed responses of the microcircuit s curise following token requests as performed by the procedures # 3 and # 4, respectively described in claims 7 and 8. Claim 10. Method according to claims 1 and 7 or 8 characterized in that a security token issued by a server generating tokens following a signed request from a secure microcircuit comprises, to designate the owner of the token, a field containing the pseudonym of an already known owner of the target server and that, because of the process leading to its incorporation into the token, this pseudonym can only have been generated by a secure microcircuit using a pseudo-random generator and that consequently its value can not have been freely chosen by anyone. Claim 11. The method of claims 1 and 7 or 8 characterized in that a security token issued by a server generating tokens, following a signed request from a secure microcircuit, comprises to designate the target server to which the token is intended, a sequence of bytes that is not interpretable by the server generating tokens, because this sequence of bytes is first locally calculated by the client application using a hash function and two input parameters a salting value and an identifier of the target server, then communicated to the token-producing server as a parameter of the request to be embedded in the token and accordingly when the client application communicates with the target server concomitantly with the token , this identifier and this salting value, the latter can, thanks to these two values, recognize each other and then combine these two values using the hash function to retrieve See the representative byte sequence present in the token so that the target server can verify that the security token is actually intended for it. Claim 12. The method of claims 5, 6, 7 and 8 characterized in that the agreement of the legitimate user of the secure microcircuit mentioned in the above claims is obtained: (a) by the presentation of a PIN code (Personal Identification Number) or an activation code by the legitimate owner of the secure microcircuit that is required to authorize certain operations related to the authentication; this PIN code being called in this case an "elD-PIN", (b) by the comparison by the secure microcircuit of a biometric data specific to the legitimate user of the secure microcircuit which is necessary to authorize certain operations related to the (c) by a combination of an elD-PIN and a biometric data specific to the legitimate user of the secure microcircuit. Claim 13. The method of claims 1,2, 5, 6, 7, 8 and 12 characterized in that the secure microcircuit used in the context of the method must have the usual properties of a "security module" ("security module"). "in English) or a secure element (" secure element "in English) in the sense of the rules of the art, and in particular, a resistance to external physical attacks, resistance to differential cryptographic attacks, the impossibility of being able to duplicate the content of the secure microcircuit if it does not allow it, and moreover, must contain the data described in claim 2, must support the procedure n ° 1, must support the procedure n ° 3 if it supports the procedure 2, must support procedure 4 if it supports procedure 2 and must comply with the requirements specified in claim 12. Claim 14. Method according to claims 1 and 7 or 8, and 13 characterized in that a token-producing server accepts to issue a security token following a token request for a user identified by a given pseudonym that s it is able to verify that: (1) it is not the replay of a token request, either by checking that the challenge matches the one that was sent, or by checking that the unique number is within the allowed time range and that this unique number is not already among the unique numbers stored during this time range, (2) the pseudonym designating the token-producing server in the token request is known to it, (3) the account attached to this pseudonym is neither temporarily nor permanently invalidated, (4) the token request is actually signed by the private key associated with the account, (5) the public information corresponding to the private key of the secure microcircuit q ui was implemented when opening the account or at the latest when the request for the token is still valid or is neither expired nor revoked, (6) the public information has been issued by a trusted authority that delivers such information only after making sure that the secure microcircuit meets a precise specification allowing it to know that all the security requirements applicable to the secure microcircuit and which are described in claim 13 are respected. Claim 15. Method according to claims 1,5, 10, 11 and 14, characterized in that a target server will not agree to associate, after the usual checks, to an account opened under a pseudonym the attributes contained in a security token, that: (1) if an account has already been opened on this server under the alias contained in the ad-hoc field of the security token, and (2) if this account is neither temporarily nor permanently invalidated and (3) if the date on which the token was issued is close to the present time or if a validity period is indicated in the token, if the present time is included in that validity period, and (4) if the target server recognizes itself as a token recipient, and (5) if the security token has been signed by a known token-producing server of the target server to perform all the checks prescribed in claim 14.