WO2012001272A1 - Procede d'authentification permettant de renforcer l'anonymat entre un fournisseur d'identites et un fournisseur de services - Google Patents

Procede d'authentification permettant de renforcer l'anonymat entre un fournisseur d'identites et un fournisseur de services Download PDF

Info

Publication number
WO2012001272A1
WO2012001272A1 PCT/FR2011/051441 FR2011051441W WO2012001272A1 WO 2012001272 A1 WO2012001272 A1 WO 2012001272A1 FR 2011051441 W FR2011051441 W FR 2011051441W WO 2012001272 A1 WO2012001272 A1 WO 2012001272A1
Authority
WO
WIPO (PCT)
Prior art keywords
identity
authentication
user
knowledge
provider
Prior art date
Application number
PCT/FR2011/051441
Other languages
English (en)
Inventor
Sébastien CANARD
Jacques Traore
Original Assignee
France Telecom
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom filed Critical France Telecom
Publication of WO2012001272A1 publication Critical patent/WO2012001272A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • 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/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3218—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • H04L9/3221—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs interactive zero-knowledge proofs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/42—Anonymization, e.g. involving pseudonyms

Definitions

  • the present invention relates to the authentication domain, in particular that of the single authentication of a user by an identity provider when this user requires an identity provider. access to a service provider.
  • the invention finds a particularly advantageous application in the field of single-sign-on systems enabling a user having several identities with several service providers to federate his identities, that is to say to establish logical links between them , and to benefit from a single authentication service, otherwise called SSO (for "Single Sign-On” in English) to access the various service providers without having to authenticate several times.
  • SSO Single Sign-On
  • the standard authentication mechanisms on which the present invention is based assume that the user has previously opened, with the identity provider and respectively with the service providers, an account identified by a local identity (user @ idp, respectively user @ sp) by registering on the basis of respective user names, each of these usernames may be, depending on the respective policy of the identity provider and each service provider, the civil (certified) ) of the user, a pseudonym.
  • Authentication with an identity provider or service provider is for the user to prove that he is the entity corresponding to the username on which he opened an account , and for the identity provider or the service provider, to refer, after verification, to the local identity associated with that user.
  • a first family of first-generation single sign-on solutions is to implement a unique local identity shared by the identity provider and the different service providers.
  • Single sign-on systems such as Tivoli Access Manager from IBM rely on this type of approach.
  • a disadvantage of these systems is that the identity provider and the different service providers, who have the unique identity of the user, can then cross their client databases and thus violate the privacy of users.
  • a second family of first-generation single sign-on solutions is to implement an identity federation. The user has different identities (otherwise known as aliases) at the identity provider and the different service providers, and the user establishes logical links between these different identities so that the set ultimately constitutes a logically unique identity. but physically distributed.
  • Standards such as Liberty Alliance Liberty or SAML OASIS define identity federation mechanisms and single authentication between services based on such federation of identities.
  • the mechanisms specified by the Liberty Alliance or OASIS allow users to federate their identities dynamically and online. They also allow a service provider to benefit from a certified identity delivered by an identity provider and thus to free the user wishing to consume a service of a new authentication phase.
  • identity providers can instead provide a reference, called the "federation alias," associated with that user, with the federation alias provided by the identity provider for a user being different for each provider. Services.
  • each entity whether the identity provider or the service provider, creates for each user a lookup table between the user's local identity and the respective aliases used by each other. entities. Single sign-on is then possible once the identities of a user at the identity provider and each service provider are federated.
  • the Liberty and OASIS standards therefore offer a SSO mechanism that guarantees a first level of privacy.
  • an identity provider provides a different federation alias for each service provider. Service providers can not use these aliases to cross their client databases to obtain information about user practices and habits in terms of accessing services.
  • the Identity Provider has all the federation aliases, and therefore the necessary and sufficient information to cross-check the client databases. This fraudulent cross-checking operation can be carried out on the initiative of the identity provider himself or of a third party having managed to access the data held by the identity provider.
  • a blind signature scheme is a protocol involving two entities: a user and a signer. It allows the user to obtain from the signatory the signature of a given message, without the latter learning anything about the message.
  • the use of a blind signature scheme enables the identity federation table to be managed and controlled on the client side, while maintaining the authentication mechanism on the network side, by identity provider.
  • the identity provider has a perfect knowledge of the identity of the service providers that a user accesses and can thus correlate all the interests of a particular user. Likewise, the service provider knows the identity provider.
  • the identity management mechanisms described above thus lack an identity federation mechanism and SSO in which the user's privacy is fully safeguarded by reinforcing the mutual anonymity between a service provider and a service provider. identity provider used by a user during a single sign-on.
  • the object of the present invention is to improve the situation.
  • the sending and the verification of the first proof of knowledge takes place during an identity federation step which furthermore comprises:
  • Such an identity federation step then makes it possible to obtain a unique authentication method.
  • the first proof of knowledge is further calculated from the public key and at least part of the validity certificate.
  • the first proof of knowledge comprises at least a first masked value calculated from the public key, a second masked value calculated from at least a part of the validity certificate and a third masked value calculated from partial signature.
  • the method comprises a preliminary step of registration, prior to the identity federation, of the identity provider with a certification authority including the sending by the certification authority to the provider of the identity.
  • identity of the validity certificate calculated from at least one commitment sent by the identity provider. This makes it possible to certify the validity of the signature made by the identity provider through a third authority.
  • the commitment sent by the identity provider is a commitment on a first element randomly chosen by the identity provider.
  • the secret key used by the identity provider comprises the first element randomly chosen by the identity provider and a second element chosen randomly by the certification authority.
  • the authentication request comprises at least one blinded portion by the user, one of said at least one blinded portion comprising the identity of the service provider.
  • each subsequent authentication step comprises sending a new proof of knowledge obtained from a partial signature calculated by the identity provider from a new blind alias and secret key, followed by verification of said new evidence of knowledge by the service provider.
  • the new proof of knowledge is calculated so as to be different from the first proof of knowledge computed during identity federation and, if the method comprises several subsequent authentication steps. , new proofs of knowledge calculated during the other subsequent authentication steps.
  • the first proof of knowledge is calculated according to a first and a second random variable and the new proof of knowledge is calculated according to a first and a second subsequent random variable, said first and second subsequent random variables being chosen. to be different from said first and second random variables and, if the method comprises several subsequent authentication steps, first and second subsequent random variables ferj *) selected in the further subsequent authentication steps.
  • an authentication message comprising a blind alias of the user is sent to the service provider at each subsequent authentication step, and each subsequent authentication step includes the blindness of the user's alias so that the blinded alias obtained is different from the blind alias obtained during the identity federation step and, if the method comprises several subsequent authentication steps, other blinded aliases obtained during the other subsequent authentication steps .
  • the blinded alias obtained during the identity federation step is calculated according to the alias of the user and a random variable
  • the blind alias obtained during a subsequent step of authentication is calculated according to the alias of the user and a subsequent random variable, said subsequent random variable being chosen to be different from said random variable and, if the method comprises several subsequent authentication steps, random variables subsequent ones chosen during the other subsequent authentication steps.
  • the present invention furthermore proposes a reinforced anonymity authentication system comprising at least one user, at least one service provider, an identity provider and a certification authority, this system being able to implement the method of authentication. authentication above when said at least one user requires a service from one of said at least one service provider.
  • the present invention also proposes a computer program, downloadable via a telecommunication network and / or stored in a memory of a central unit and / or stored on a memory medium intended to cooperate with a central unit, this computer program being able to implement the authentication method above.
  • the authentication method which is the subject of the invention, will be better understood on reading the description and on observing the following drawings in which:
  • FIG. 1 illustrates the steps of an authentication method allowing enhanced anonymity between an identity provider and a service provider according to the present invention
  • FIG. 2 illustrates an embodiment of the substeps comprising a preliminary registration step according to the present invention
  • FIG. 3 illustrates the substeps of an identity federation step 200 according to the present invention.
  • This authentication method takes place in a strengthened anonymity authentication system comprising at least one U user, at least one SP service provider, an IdP identity provider and a CA certification authority.
  • a strengthened anonymity authentication system comprising at least one U user, at least one SP service provider, an IdP identity provider and a CA certification authority.
  • a single user U and a single service provider are shown in Figure 1, although any number of users and / or service providers may be affected by the method of the present invention.
  • a preliminary step of registering an identity provider is first performed (step 100). Such a preliminary step may occur during initialization of the authentication system, when an entity wishes to become an IdP identity provider or when an identity provider IdP wishes to provide one of its clients with a service of authentication. Protection of private life.
  • This preliminary registration step includes a number of interactions between an IdP identity provider, whose role is to authenticate the user U when seeking to access the service provider SP, and a certificate authority CA whose role is to certify the validity of a signature calculated by the identity provider IdP from an authentication message received from the user and intended for the service provider.
  • the identity provider IdP receives from the CA a validity certificate ⁇ of a public key t associated with a secret key used by the identity provider IdP to sign U user messages
  • an identity federation step takes place, during which the identity provider IdP uses its secret key y to sign a user authentication message.
  • the user U After obtaining the signature of the authentication message of the user by the identity provider, the user U calculates a proof of knowledge W of the validity certificate ⁇ of the key public t associated with the secret key used by the identity provider IdP for signing the authentication message of the user U. The user U then sends it to the service provider SP with the authentication message, so that it can authenticate the user U by verifying the said proof of knowledge.
  • the service provider SP does not have direct access to the identity of the IdP identity provider, whose anonymity is preserved. Indeed, the proof of knowledge computed by the user proves that the signature of the authentication message comes from a valid identity provider without revealing elements of this signature.
  • a subsequent authentication step (step 300) is then performed, based on a new authentication request, this step taking place always without the SP service provider having direct access to the identity of the IdP identity provider, whose anonymity is still preserved.
  • a subsequent authentication step is illustrated in FIG. 1, any number of successive subsequent authentication steps can take place.
  • FIG. 2 illustrates an embodiment of the substeps of the preliminary recording step 100.
  • this preliminary registration step includes a number of interactions between an IdP identity provider and a CA.
  • the certification authority CA has a public / secret key pair (capk, cask) for a signature algorithm, for example a signature algorithm with extensions as described in the article "Signature schemes and anonymous credentials from bilinear maps. From Camenisch and Lysyanskaya.
  • Generators g 1 and h of this group G can also be chosen.
  • an extended signature scheme will be used to allow a signer, in this case the IdP identity provider, to sign values that arrive in an engaged form.
  • This preliminary registration step can then proceed as follows:
  • the certification authority CA calculates the signature ⁇ of the commitment C by means of the signing procedure SIGN with extensions of this commitment, by using the secret key cask. This can be done, for example, by randomly choosing, in Z p , a first element a and
  • the signature ⁇ then corresponds to the pair of elements (A, a).
  • This signature ⁇ corresponds to a certificate of validity of the public key t signature of the identity provider IdP, issued by the CA and can be used to prove to third parties the validity of this public key t.
  • the identity provider IdP verifies by means of the public key capk that the signature ⁇ is the signature of the element y (substep 115).
  • FIG. 3 illustrates the substeps of identity federation step 200.
  • an identity federation step 200 takes place so that the user U can federate in a first time. time identity at the SP service provider and IdP identity provider.
  • the service provider SP does not become aware of the identity of the identity provider IdP during this federation step d 'identities.
  • the SP Service Provider is simply satisfied, by evidence, that an IdP Identity Provider, whose identity has been certified by the CA, has authenticated User U as required single sign-on.
  • a blind signature scheme, implemented by the identity provider IdP, of a msg authentication message divided into three parts M, m and m * is used here.
  • This identity federation step 200 can then proceed as follows:
  • the user U requires access to a service of the service provider SP, by means of a first access request REQ (SERV) (substep 201 of sending an access request). 2) Following the reception of this first access request REQ (SERV), the service provider SP sends a signed authentication request REQ (AUTH) so that the user U starts the steps to authenticate (sub-) step 203 of sending an authentication request).
  • SERP first access request REQ
  • AUTH signed authentication request
  • the user U After receiving this authentication request, the user U constructs an authentication message msg during a sub-step 204 for constructing an authentication message.
  • This msg authentication message includes:
  • a first part M gathering non-blinded elements for example SAML tags, the identity of the SP service provider, the name of the signature algorithm, or other fields and / or attributes of a request SAML which does not allow to link the final request to the authentication request,
  • SAML tags for example SAML tags, the identity of the SP service provider, the name of the signature algorithm, or other fields and / or attributes of a request SAML which does not allow to link the final request to the authentication request
  • the user U calculates a first proof V of knowledge of the representation (H (m), r) of the first blinded element c in bases (h ! , h 4 ).
  • the user also calculates a second proof V * of knowledge of the representation (s, r *) of the second blinded element c * in bases (h, h 4 ).
  • the user U sends to the identity provider IdP the first part M of the message msg, the first and second blind elements c and c *, as well as their respective proofs of knowledge V and V * (submitting step 209).
  • This sending can advantageously be accompanied by authentication of the user with the identity provider IdP, according to a method chosen by the latter, for the needs of the user.
  • blind signature as well as identity federation, in that the IdP identity provider has the role of authenticating the user U.
  • the identity provider IdP can associate, in its federation base, blind alias c * of the user U at the service provider SP to a local account user @ idp of the user at the IdP identity provider.
  • the signature of the commitment C "then corresponds to the triplet (S, w, k).
  • the identity provider IdP sends this signature (S, w, k) of the commitment C" to the user U when the a substep 215 of commitment signature sending.
  • This proof W of knowledge is also used to prove the knowledge of the public key t and the certificate of validity of the signature K, without revealing these two values.
  • the proof W of knowledge can thus be calculated such that:
  • a first hidden variable associated with the public key t is calculated from the public key t as follows:
  • a third hidden variable associated with the partial signature S belonging to the signature ⁇ is calculated from this partial signature S as follows:
  • the fourth hidden variable C is associated with the variable A of the certificate ⁇ (and depends on it), and the fifth hidden variable C g as well as the sixth hidden variable C g are associated with the partial signature S (and depend on these).
  • the proof of knowledge W then comprises at least the six hidden variables C t , C s ,
  • the proof W of knowledge is then sent by the user U to the service provider SP, during a step 223 transmission of proof of knowledge.
  • the service provider SP does not directly receive the public key t, the certificate ⁇ and the signature ⁇ , which does not allow him to find the identity of the identity provider IdP.
  • the received masked variables, associated with one of these three elements make it possible to verify the knowledge of these three elements by the user.
  • the sending of this proof of knowledge W is accompanied by the sending of the msg authentication message.
  • the part m * of this message namely the alias of the user U, can then be associated with a local account user @ sp in a client base of the service provider, which allows the federation of identities between the local accounts of the IdP identity provider and the SP service provider.
  • the federation is managed by the user U in order to preserve the anonymity of the latter with these two entities.
  • the verification of the proof of knowledge W is performed, during a sub-step 225 of verification, by the service provider.
  • This verification of the proof of knowledge may comprise the verification of equations (1) and (2) as defined above.
  • Verification of the proof of knowledge then consists of checking the following equation (5):
  • W POK (v t , w t , v A , w t , av A , aw A , v s , w s , v s k, w s k, v s v t , w s v t , a, w, r + r, k:
  • the service provider SP then gives access (substep 227 of access to the service) to the user to the required service.
  • the identity federation 200 previously described takes place during the first access of the user to the service provider SP, that is to say when sending a first access request from the user to the provider. of SP services.
  • the same user subsequently submits a new access request to the same service provider SP, his identity has already been federated and a subsequent authentication step 300 will then take place, for each sending of a new access request to the provider. services, using aliases already federated.
  • Such a subsequent authentication step is relatively similar to the identity federation described above.
  • the user U must send to the service provider SP, during each subsequent authentication step, the same alias m * as that which has been validated during the identity federation, in order to to allow the service provider SP to find the identity of the user U associated with this alias m * in his customer base
  • the user U does not need to prove that he uses, during the generation of the proof of knowledge, the same alias m * as in the preliminary stage of federation of identities. Indeed, if the user U does not follow the authentication protocol described above, for example by using an alias other than m *, it will not be able to be authenticated by the service provider SP since the latter will not recognize the alias he had previously received.
  • a new proof of knowledge W is calculated at each subsequent authentication step of the user U with the service provider SP. This new proof of knowledge is different from the proofs of knowledge computed during the identity federation step 200 and the previous authentication steps 300, in order to ensure that the provider of services SP is untraceable by the provider.
  • Identity IdP is calculated at each subsequent authentication step of the user U with the service provider SP.
  • the identity provider IdP can make the link with the information gathered during the preliminary stage of identity federation.
  • the random values r and r * may be chosen to be different.
  • FIG. 4 illustrates the substeps constituting such a step of subsequent authentication.
  • Such a subsequent authentication step 300 proceeds as follows: 1) The user U requires access to a service of the service provider SP, by means of an access request REQi (SERV) (sub- step 301 of sending an access request).
  • REQi access request REQi
  • the service provider SP Following reception of this access request REQi (SERV), the service provider SP sends a subsequent authentication request REQi (AUTH) signed so that the user U begins the steps to authenticate again ( sub-step 303 of sending an authentication request).
  • REQi access request
  • AUTH authentication request
  • the user U After receiving this authentication request, the user U constructs a subsequent authentication message msg i> (authentication message construction sub-step 304) comprising a first part Mj gathering non-blinded elements, a second part ⁇ 3 ⁇ 4 gathering blind elements variable from one access to another, and a third part m * including invariant blind elements from one access to another, namely alias of the user.
  • authentication message construction sub-step 304 comprising a first part Mj gathering non-blinded elements, a second part ⁇ 3 ⁇ 4 gathering blind elements variable from one access to another, and a third part m * including invariant blind elements from one access to another, namely alias of the user.
  • the user U calculates a first proof Vj of knowledge of the first element blinded in bases (h !, H 4 ), as well as a second proof Vj * knowledge of the second element blinded c * bases (h, h 4 ), similar to what is done in step 207.
  • the user U sends to the identity provider IdP the first part Mj of the message msgi, the first and second blind elements Cj and (1 ⁇ 4 *, as well as their respective proofs of knowledge Vj and Vj * (substep of sending 309) 7)
  • the identity provider IdP calculates a commitment value Ci "containing commitments on Mj, ⁇ 3 ⁇ 4 , m * and a so-called randomization value ⁇ * + ⁇ , similarly to step 211 (calculation sub-step 311).
  • the identity provider IdP sends this signature (Si, Wj, 3 ⁇ 4) to the user U during a substep 315 sending commitment signature.
  • This new proof Wj of knowledge is also used to prove the knowledge of the public key t and the certificate of validity of the signature ⁇ , without revealing these two values.
  • the new proof Wj of knowledge is calculated similarly to the step 221 of the federation of identities (substep of calculation 321): 14) Once computed, the new proof Wj of knowledge is then sent by the user U to SP service provider, during a step 323 transmission of new proof of knowledge.
  • the service provider SP does not directly receive the public key t, the certificate ⁇ and the signature ⁇ , which does not allow him to find the identity of the identity provider IdP.
  • the service provider SP receives a new proof Wj of knowledge, different from the proof W of knowledge used during the federation of identities, as well as proofs of knowledge Wi, ... Wn used in the eventual preceding steps d authentication, which guarantees the infeasibility of the SP service provider. 15) Following the receipt of the new proof Wj of knowledge, the verification of this new proof Wj of knowledge is then carried out during a verification sub-step 325 similar to the step 225 described above.
  • the identity provider IdP it is not necessary to use the identity provider IdP during the subsequent authentication step.
  • the authentication of the user U can be made possible by the knowledge of the discrete logarithm of alias m 'in the base h.
  • the service provider SP then verifies this proof of knowledge of the discrete logarithm by the user U and gives access to his services if this verification is positive.
  • the anonymity of the identity provider IdP with the service provider SP is guaranteed, which reinforces the anonymity between these two entities.
  • the identity of the SP service provider is included in part M not blinded the authentication message.
  • the identity provider IdP therefore has access to the identity of the service provider SP and can thus obtain from its customer base (or federation base) information on the interests of the user U.
  • the identity of the service provider SP is placed in the variable blind portion m of the authentication message, during the identity federation step 200 as well as during the possible subsequent authentication steps 300, in order to guarantee the anonymity of the SP service provider with the identity provider IdP, which makes it possible to further reinforce the anonymity between these two entities.
  • the service provider SP signs the authentication request with a group signature before sending this request to the user U, during substeps 203 and 303, in order to remain anonymous. to the IdP identity provider.
  • a particular embodiment can then be that the identity of the service provider SP is placed in the part blinded invariant m * (in addition to the user's alias) rather than in the blinded variable m of the authentication message.
  • the terms "user”, “service provider”, “identity provider” and “certifying authority” previously used cover the hardware entities used respectively by a user, a service provider, an identity provider and a service provider. certification authority.
  • Such hardware entities may take the form of a computer or a server capable of performing the operations described above, whether in terms of calculation or generation of random data.
  • this hardware entity When sending (respectively receiving) a message or a request by one of these hardware entities is indicated above, this means that this hardware entity has a hardware interface for transmission (respectively reception). ) using conventional means of data transfer, such as cable or wireless, which will not be described in more detail here but are known in the art.

Abstract

L'invention concerne un procédé d'authentification d'un utilisateur (U) auprès d'au moins un fournisseur de services (SP), ledit procédé comprenant l 'envoi (223), par l'utilisateur au fournisseur de services, d'une première preuve de connaissance (W) d'un certificat de validité ( κ) d ' une c lé publique ( t) associée à une clé secrète (y) utilisée par un fournisseur d'identités (IdP) pour signer une première requête d'authentification de l'utilisateur et la vérification (225 ) de cette preuve de connaissance par le fournisseur de services. L'invention concerne également un système apte à mettre en œuvre un tel procédé ainsi qu'un programme d'ordinateur correspondant.

Description

Procédé d' authentification permettant de renforcer l'anonymat entre un fournisseur d'identités et un fournisseur de services La présente invention concerne le domaine de authentification, en particulier celui de authentification unique d'un utilisateur par un fournisseur d'identités lorsque cet utilisateur requiert l'accès à un fournisseur de services.
L'invention trouve une application particulièrement avantageuse dans le domaine des systèmes à authentification unique permettant à un utilisateur disposant de plusieurs identités auprès de plusieurs fournisseurs de service de fédérer ses identités, c'est-a-dire d'établir des liens logiques entre elles, et de bénéficier d'un service d'authentification unique, autrement appelé SSO (pour "Single Sign-On" en anglais) pour accéder aux divers fournisseurs de service sans avoir à s'authentifier plusieurs fois.
Les mécanismes d'authentification classiques sur lesquels s'appuie la présente invention supposent que l'utilisateur a préalablement ouvert, auprès du fournisseur d'identités et respectivement auprès des fournisseurs de services, un compte identifié par une identité locale (user@idp, respectivement user@sp) en s'enregistrant sur la base de noms d'utilisateur respectifs, chacun de ces noms d'utilisateur pouvant être, selon la politique respective du fournisseur d'identités et de chaque fournisseur de services, soit le patronyme civil (certifié) de l'utilisateur, soit un pseudonyme.
L'authentification auprès d'un fournisseur d'identités ou d'un fournisseur de services consiste, pour l'utilisateur, à prouver qu'il est bien l'entité correspondant au nom d'utilisateur sur la base duquel il a ouvert un compte, et pour le fournisseur d'identités ou le fournisseur de services, à se référer, après vérification, à l'identité locale associée à cet utilisateur.
Dans l'état de la technique, plusieurs systèmes offrant des fonctionnalités de fédération d'identités ont été initialement proposés, mettant en œuvre un mécanisme consistant pour un utilisateur à s'authentifier une première fois auprès d'un fournisseur d'identités IdP ("Identity Provider" en anglais) et à accéder ensuite à des fournisseurs de services SP ("Service Provider" en anglais) sans devoir s'authentifier à nouveau.
Une première famille de solutions de première génération d'authentification unique consiste à mettre en œuvre une identité locale unique partagée par le fournisseur d'identités et les différents fournisseurs de services. Des systèmes d'authentification unique tels que Tivoli Access Manager d'IBM s'appuient sur ce type d'approche. Un inconvénient de ces systèmes est que le fournisseur d'identités et les différents fournisseurs de services, qui disposent de l'identité unique de l'utilisateur, peuvent alors croiser leurs bases de données clients et donc porter atteinte a la vie privée des utilisateurs. Une seconde famille de solutions de première génération d'authentification unique consiste à mettre en œuvre une fédération d'identités. L'utilisateur a des identités différentes (autrement appelées alias) chez le fournisseur d'identités et les différents fournisseurs de services, et l'utilisateur établit des liens logiques entre ces différentes identités de sorte que l'ensemble constitue in fine une identité logiquement unique mais physiquement distribuée.
Des standards tels que Liberty de l'Alliance Liberty ou SAML de I'OASIS définissent des mécanismes de fédération d'identités et d'authentification unique entre services s'appuyant sur une telle fédération d'identités.
Les mécanismes spécifiés par l'Alliance Liberty ou I'OASIS permettent aux utilisateurs de fédérer leurs identités dynamiquement et en ligne. Ils permettent également à un fournisseur de services de bénéficier d'une identité certifiée et délivrée par un fournisseur d'identités et donc d'affranchir l'utilisateur souhaitant consommer un service d'une nouvelle phase d'authentification.
Lorsqu'un utilisateur se connecte pour la première fois à un fournisseur de services pour s'authentifier auprès de ce fournisseur de services, il se voit offrir la possibilité de fédérer son identité chez le fournisseur de services avec son identité chez un fournisseur d'identités.
Contrairement à l'approche adoptée par des produits de la première famille de solutions ci- avant (Tivoli Access Manager d'IBM par exemple), les standards Liberty et SAML n'imposent pas aux fournisseurs d'identités de fournir l'identité locale d'un utilisateur. Au contraire, les fournisseurs d'identités peuvent, à la place, fournir une référence, appelée « alias de fédération », associée à cet utilisateur, l'alias de fédération fourni par le fournisseur d'identités pour un utilisateur étant différent pour chaque fournisseur de services.
Dans une fédération d'identités, chaque entité, que ce soit le fournisseur d'identités ou les fournisseurs de services, crée pour chaque utilisateur une table de correspondance entre l'identité locale de l'utilisateur et les alias respectifs utilisés par chacune des autres entités. L'authentification unique est alors possible une fois que les identités d'un utilisateur chez le fournisseur d'identités et chaque fournisseur de services sont fédérées.
Du point de vue de l'utilisateur, l'authentification unique est réalisée quand l'utilisateur s'authentifie auprès d'un fournisseur d'identités et accède à plusieurs fournisseurs de services affiliés sans avoir à s'authentifier à nouveau. Cet avantage est obtenu après avoir fédéré les identités locales de l'utilisateur entre le fournisseur d'identités et les divers fournisseurs de services.
Les standards de Liberty et de I'OASIS offrent donc un mécanisme de SSO garantissant un premier niveau de respect de la vie privée. En effet, dans le mécanisme de fédération d'identités qu'ils proposent, un fournisseur d'identités fournit un alias de fédération différent pour chaque fournisseur de services. Les fournisseurs de services ne peuvent donc pas utiliser ces alias pour croiser leurs bases de données clients afin d'obtenir des informations sur les pratiques et les habitudes des utilisateurs en termes d'accès à des services. En revanche, le fournisseur d'identités dispose, quant à lui, de tous les alias de fédération, et donc des informations nécessaires et suffisantes pour pouvoir recouper les bases clients. Cette opération de recoupement frauduleuse peut être réalisée à l'initiative du fournisseur d'identités lui- même ou d'un tiers ayant réussi à accéder aux données détenues par le fournisseur d'identités.
Afin de répondre à cet inconvénient, une deuxième génération de solutions a été proposée par la suite permettant de garantir un deuxième niveau, plus élevé, de protection de la vie privée. Une telle solution est décrite dans la demande PCT WO 2008/113951. Cette deuxième génération de solutions consiste à permettre aux utilisateurs de fédérer leurs identités sans que ni les fournisseurs d'identités, ni les fournisseurs de services, n'aient les informations leur permettant de croiser leurs bases de données client.
Cette deuxième génération de solutions s'appuie sur le concept de signature aveugle introduit par Chaum à la conférence Crypto'83. Un schéma de signature aveugle est un protocole mettant en jeu deux entités : un utilisateur et un signataire. Il permet à l'utilisateur d'obtenir du signataire la signature d'un message donné, sans que ce dernier n'apprenne quoi que ce soit à propos du message.
Dans le contexte de l'authentification unique, l'utilisation d'un schéma de signature aveugle permet de gérer et de contrôler la table de fédération d'identités du côté client, tout en maintenant le mécanisme d'authentification du côté réseau, par un fournisseur d'identités.
Cependant, avec cette deuxième génération de solutions, le fournisseur d'identités dispose d'une parfaite connaissance de l'identité des fournisseurs de services auxquels accède un utilisateur et peut donc ainsi corréler tous les centres d'intérêt d'un utilisateur en particulier. De même, le fournisseur de services connaît le fournisseur d'identités.
Il manque donc aux mécanismes de gestion de l'identité décrits ci-avant un mécanisme de fédération d'identités et de SSO dans lequel la vie privée de l'utilisateur est totalement sauvegardée en renforçant l'anonymat réciproque entre un fournisseur de services et un fournisseur d'identités utilisés par un utilisateur lors d'une authentification unique.
La présente invention a pour objet d'améliorer la situation.
Elle propose à cette effet un procédé d'authentification d'un utilisateur auprès d'au moins un fournisseur de services, ledit procédé comprenant l'envoi, par l'utilisateur au fournisseur de services, d'une première preuve de connaissance d'un certificat de validité d'une clé publique associée à une clé secrète utilisée par un fournisseur d'identités pour signer une première requête d'authentification de l'utilisateur et la vérification de cette preuve de connaissance par le fournisseur de services. Grâce à l'envoi d'une telle preuve de connaissance, au lieu de l'envoi de la signature ou de la clé publique qui révéleraient l'identité du fournisseur d'identités, il est possible de garantir l'anonymat de ce fournisseur d'identités auprès du fournisseur de services, et de renforcer ainsi l'anonymat réciproque entre ces deux fournisseurs.
Avantageusement, l'envoi et la vérification de la première preuve de connaissance ont lieu durant une étape de fédération d'identités qui comprend, en outre :
- l'envoi au fournisseur d'identités d'un alias aveuglé calculé à partir d'un alias de l'utilisateur ;
- le calcul par l'utilisateur de la première preuve de connaissance à partir d'une signature partielle calculée par le fournisseur d'identités à partir de l'alias aveuglé et de la clé secrète ;
- l'envoi au fournisseur de services de l'alias de l'utilisateur avec la première preuve de connaissance.
Une telle étape de fédération d'identités permet alors d'obtenir un procédé d'authentification unique.
Avantageusement, la première preuve de connaissance est calculée en outre à partir de la clé publique et d'au moins une partie du certificat de validité.
De façon particulièrement avantageuse, la première preuve de connaissance comprend au moins une première valeur masquée calculée à partir de la clé publique, une deuxième valeur masquée calculée à partir d'au moins une partie du certificat de validité et une troisième valeur masquée calculée à partir de la signature partielle.
Dans un mode de réalisation avantageux, le procédé comprend une étape préliminaire d'enregistrement, préalable à la fédération d'identités, du fournisseur d'identités auprès d'une autorité de certification comprenant l'envoi par l'autorité de certification au fournisseur d'identités du certificat de validité calculé à partir d'au moins un engagement envoyé par le fournisseur d'identités. Ceci permet de certifier la validité de la signature effectuée par le fournisseur d'identités par le biais d'une autorité tiers.
Avantageusement, l'engagement envoyé par le fournisseur d'identités est un engagement sur un premier élément choisi aléatoirement par le fournisseur d'identités.
De manière particulièrement avantageuse, la clé secrète utilisée par le fournisseur d'identités comprend le premier élément choisi aléatoirement par le fournisseur d'identités ainsi qu'un deuxième élément choisi aléatoirement par l'autorité de certification.
Avantageusement, lors de l'étape de fédération d'identités, la requête d'authentification comprend au moins une partie aveuglée par l'utilisateur, une desdites au moins une partie aveuglée comprenant l'identité du fournisseur de services.
Dans un mode de réalisation avantageux où le procédé comprend au moins une étape ultérieure d'authentification, chaque étape ultérieure d'authentification comprend l'envoi d'une nouvelle preuve de connaissance obtenue à partir d'une signature partielle calculée par le fournisseur d'identités à partir d'un nouvel alias aveuglé et de la clé secrète, suivi de la vérification de ladite nouvelle preuve de connaissance par le fournisseur de services.
De manière avantageuse, pour chaque étape ultérieure d' authentification, la nouvelle preuve de connaissance est calculée de sorte à être différente de la première preuve de connaissance calculée lors de la fédération d'identités et, si le procédé comprend plusieurs étapes ultérieures d' authentification, des nouvelles preuves de connaissance calculées lors des autres étapes ultérieures d' authentification.
Avantageusement, la première preuve de connaissance est calculée en fonction d'une première et une deuxième variables aléatoires et la nouvelle preuve de connaissance est calculée en fonction d'une première et une deuxième variables aléatoires ultérieures, lesdites première et deuxième variables aléatoires ultérieures étant choisies pour être différentes desdites première et deuxième variables aléatoires et, si le procédé comprend plusieurs étapes ultérieures d' authentification, des première et deuxième variables aléatoires ultérieures ferj*) choisies lors des autres étapes ultérieures d' authentification.
Avantageusement, un message d' authentification comprenant un alias aveuglé de l'utilisateur est envoyé au fournisseur de services à chaque étape ultérieure d' authentification, et chaque étape ultérieure d' authentification comprend l'aveuglement de l'alias de l'utilisateur de sorte que l'alias aveuglé obtenu soit différent de l'alias aveuglé obtenu lors de l'étape de fédération d'identités et, si le procédé comprend plusieurs étapes ultérieures d' authentification, des autres alias aveuglés obtenus lors des autres étapes ultérieures d' authentification.
Avantageusement, l'alias aveuglé obtenu lors de l'étape de fédération d'identités est calculé en fonction de l'alias de l'utilisateur et d'une variable aléatoire, et l'alias aveuglé obtenu lors d'une étape ultérieure d' authentification est calculé en fonction de l'alias de l'utilisateur et d'une variable aléatoire ultérieure, ladite variable aléatoire ultérieure étant choisie pour être différente de ladite variable aléatoires et, si le procédé comprend plusieurs étapes ultérieures d' authentification, des variables aléatoires ultérieures choisies lors des autres étapes ultérieures d' authentification.
La présente invention propose en outre un système d' authentification à anonymat renforcé comprenant au moins un utilisateur, au moins un fournisseur de services, un fournisseur d'identités et une autorité de certification, ce système étant apte à mettre en œuvre le procédé d' authentification ci-avant lorsqu'un desdits au moins un utilisateur requiert un service auprès d'un desdits au moins un fournisseur de services.
La présente invention propose également un programme d'ordinateur, téléchargeable via un réseau de télécommunication et/ou stocké dans une mémoire d'une unité centrale et/ou stocké sur un support mémoire destiné à coopérer avec une unité centrale, ce programme d'ordinateur étant apte à mettre en œuvre le procédé d' authentification ci-avant. Le procédé d'authentification, objet de l'invention, sera mieux compris à la lecture de la description et à l'observation des dessins ci-après dans lesquels :
- la figure 1 illustre les étapes d'un procédé d'authentification permettant un anonymat renforcé entre un fournisseur d'identités et un fournisseur de services selon la présente invention ;
- la figure 2 illustre un mode de réalisation des sous-étapes composant une étape préliminaire d'enregistrement selon la présente invention ; et
- la figure 3 illustre les sous-étapes d'une étape de fédération d'identité 200 selon la présente invention. On se réfère tout d'abord à la figure 1 sur laquelle sont illustrées les étapes d'un procédé d'authentification permettant de renforcer l'anonymat entre un fournisseur d'identités et un fournisseur de services.
Ce procédé d'authentification se déroule dans un système d'authentification à anonymat renforcé comprenant au moins un utilisateur U, au moins un fournisseur de services SP, un fournisseur d'identités IdP ainsi qu'une autorité de certification CA. A titre purement illustratif, un seul utilisateur U et un seul fournisseur de services sont indiqués sur la figure 1, bien qu'un nombre quelconque d'utilisateurs et/ou de fournisseurs de services puisse être concerné par le procédé de la présente invention.
Dans ce procédé, une étape préliminaire d'enregistrement d'un fournisseur d'identités est tout d'abord effectuée (étape 100). Une telle étape préliminaire peut intervenir lors de l'initialisation du système d'authentification, lorsqu'une entité souhaite devenir un fournisseur d'identités IdP ou lorsqu'un fournisseur d'identités IdP souhaite fournir à l'un de ses clients un service de protection de la vie privée.
Cette étape préliminaire d'enregistrement comprend un certain nombre d'interactions entre un fournisseur d'identités IdP, dont le rôle est d'authentifier l'utilisateur U lorsque celui-ci cherche à accéder au fournisseur de services SP, et une autorité de certification CA dont le rôle est de certifier la validité d'une signature calculée par le fournisseur d'identités IdP à partir d'un message d'authentification reçu de l'utilisateur et destiné au fournisseur de services.
A l'issue de cette étape préliminaire d'enregistrement, le fournisseur d'identités IdP reçoit de l'autorité de certification CA un certificat de validité κ d'une clé publique t associée à une clé secrète y utilisée par le fournisseur d'identités IdP pour signer les messages de l'utilisateur U.
Par la suite, une étape de fédération d'identité (étape 200) a lieu, durant laquelle le fournisseur d'identités IdP utilise sa clé secrète y pour signer un message d'authentification de l'utilisateur.
Durant cette étape de fédération d'identités, après l'obtention de la signature du message d'authentification de l'utilisateur par le fournisseur d'identités, l'utilisateur U calcule une preuve de connaissance W du certificat de validité κ de la clé publique t associée à la clé secrète y utilisée par le fournisseur d'identités IdP pour signer le message d' authentification de l'utilisateur U. L'utilisateur U l'envoie ensuite au fournisseur de services SP avec le message d' authentification, afin que celui-ci puisse authentifier l'utilisateur U en vérifiant ladite preuve de connaissance.
Le fournisseur de services SP n'a ainsi pas accès directement à l'identité du fournisseur d'identités IdP, dont l'anonymat est préservé. En effet, la preuve de connaissance calculée par l'utilisateur prouve que la signature du message d' authentification provient d'un fournisseur d'identités valide sans pour autant révéler d'éléments de cette signature.
Une fois les identités fédérées, lorsque l'utilisateur cherche à nouveau à accéder au fournisseur de services, une étape ultérieure d' authentification (étape 300) est alors effectuée, sur la base d'une nouvelle requête d' authentification, cette étape se déroulant toujours sans que le fournisseur de services SP n'ait directement accès à l'identité du fournisseur d'identités IdP, dont l'anonymat est toujours préservé. Bien qu'une seule étape ultérieure d' authentification soit illustrée sur la figure 1, un nombre quelconque d'étapes ultérieures d' authentification successives peuvent avoir lieu.
On se réfère maintenant à la figure 2, qui illustre un mode de réalisation des sous-étapes de l'étape préliminaire d'enregistrement 100.
Comme indiqué précédemment, cette étape préliminaire d'enregistrement comprend un certain nombre d'interactions entre un fournisseur d'identités IdP et une autorité de certification CA.
L'autorité de certification CA dispose d'une paire de clés publique/secrète (capk, cask) pour un algorithme de signature, par exemple un algorithme de signature avec extensions tel que décrit dans l'article « Signature schemes and anonymous credentials from bilinear maps. », de Camenisch et Lysyanskaya.
On peut par exemple choisir la clé secrète cask telle que cask = y G Zp , où p est un nombre premier et la clé publique capk telle que capk = g2 r où g2 est un générateur d'un groupe G d'ordre p. Des générateurs gi et h de ce groupe G peuvent également être choisis.
Dans cette étape préliminaire d'enregistrement, un schéma de signature avec extensions va être employé afin de permettre à un signataire, en l'espèce le fournisseur d'identités IdP, de signer des valeurs qui lui parviennent sous une forme engagée.
Cette étape préliminaire d'enregistrement peut alors se dérouler de la façon suivante :
1) Le fournisseur d'identités IdP choisit aléatoirement, dans Zp , un élément y' et calcule un engagement C sur cet élément tel que C'= hy dans le groupe G (sous-étape 101). 2) Le fournisseur d'identités IdP calcule une preuve PoK de connaissance du logarithme discret y' de l'engagement C'en base y' (sous-étape 103). 3) Le fournisseur d'identités IdP envoie à l'autorité de certification CA l'engagement C et la preuve PoK. Cet envoi peut s'accompagner, de façon avantageuse, d'une authentification forte auprès de l'autorité de certification CA, par exemple une authentification à base de défi réponse mise en œuvre au moyen d'un certificat d' authentification octroyé au fournisseur d'identités IdP dans le cadre d'une infrastructure à clés publiques, ou PKI (sous-étape 105).
4) L'autorité de certification CA choisit aléatoirement, dans Zp , un élément y" et calcule un deuxième engagement C sur cet élément y" tel que C = C'hy dans le groupe G (sous-étape 107). Ce deuxième engagement se trouve être finalement un engagement sur un élément y = y' + y", qui se trouve être ainsi calculé conjointement par le fournisseur d'identités IdP et l'autorité de certification CA, mais n'est connu que par le fournisseur d'identités IdP. L'élément y servira à celui-ci de clé secrète de signature.
5) L'autorité de certification CA calcule la signature κ de l'engagement C au moyen de la procédure SIGN de signature avec extensions de cet engagement, en utilisant la clé secrète cask. Ceci peut être fait, par exemple, en choisissant aléatoirement, dans Zp , un premier élément a et en
1
calculant un deuxième élément A tel que A = (g^) r+a (sous-étape 109).
La signature κ correspond alors à la paire d'éléments (A, a).
Cette signature κ correspond à un certificat de validité de la clé publique t de signature du fournisseur d'identités IdP, délivré par l'autorité de certification CA et peut servir à prouver à des tiers la validité de cette clé publique t.
6) L'autorité de certification CA envoie alors au fournisseur d'identités l'élément y" et la signature κ = (A, a) (sous-étape 111). 7) Le fournisseur d'identités IdP calcule alors la clé privée de signature y = y' + y" (mod p)
(sous-étape 113).
8) Le fournisseur d'identités IdP vérifie au moyen de la clé publique capk que la signature κ est bien la signature de l'élément y (sous-étape 115).
Cette vérification peut se faire, par exemple, au moyen de l'équation suivante : (1) e(A,capk - g2 ) = e(gl , g2 ) - e(h, g2 )y
où e est une application bilinéaire de G x G -> GT, avec GT un groupe d'ordre p. A l'issue de ces sous-étapes, le fournisseur d'identités IdP dispose d'une clé secrète de signature y et d'une clé publique t de vérification de signature telle que t = hy.
Cette clé publique t est associée à un certificat de validité κ = (A, a) calculé par l'autorité de certification CA.
Le couple (t,K), qui vérifie la formule
Figure imgf000011_0001
est public et accessible à tous, au même titre que l'ensemble des autres couples d'éléments des fournisseurs d'identités préalablement enregistrés.
On se réfère maintenant à la figure 3, qui illustre les sous-étapes de l'étape de fédération d'identités 200.
Lorsqu'un utilisateur U souhaite accéder à un service proposé par un fournisseur de services
SP, il souhaite mettre en œuvre un processus d'authentification unique à l'aide de son fournisseur d'identités IdP préalablement enregistré auprès d'une autorité de certification comme décrit précédemment.
Conformément à un schéma d'authentification unique, lorsque l'utilisateur U souhaite accéder pour la première fois à un service du fournisseur de services SP, une étape de fédération d'identités 200 a lieu afin que l'utilisateur U puisse fédérer dans un premier temps ses identités chez le fournisseur de services SP et chez le fournisseur d'identités IdP.
Dans la présente invention, à la différence de ce qui a été décrit dans l'état de la technique précédemment discuté, le fournisseur de services SP ne prend pas connaissance de l'identité du fournisseur d'identités IdP lors de cette étape de fédération d'identités. Le fournisseur de services SP est simplement convaincu, au moyen d'une preuve, qu'un fournisseur d'identités IdP, dont l'identité a été certifiée par l'autorité de certification CA, a bien authentifié l'utilisateur U conformément aux besoins de l'authentification unique.
On utilise ici un schéma de signature aveugle, mis en œuvre par le fournisseur d'identités IdP, d'un message d'authentification msg divisé en trois parties M, m et m*.
Cette étape 200 de fédération d'identités peut alors se dérouler de la façon suivante :
1) L'utilisateur U requiert l'accès à un service du fournisseur de services SP, au moyen d'une première requête d'accès REQ(SERV) (sous-étape 201 d'envoi d'une requête d'accès). 2) Suite à la réception de cette première requête d'accès REQ(SERV), le fournisseur de services SP envoie une requête d'authentification REQ(AUTH) signée afin que l'utilisateur U entame les démarches pour s'authentifier (sous-étape 203 d'envoi d'une requête d ' authentification) .
3) Après réception de cette requête d'authentification, l'utilisateur U construit un message d'authentification msg lors d'une sous-étape 204 de construction de message d' authentification.
Ce message d'authentification msg comprend :
- une première partie M rassemblant des éléments non-aveuglés, comme par exemple des balises SAML, l'identité du fournisseur de services SP, le nom de l'algorithme de signature, ou d'autres champs et/ou attributs d'une requête SAML qui ne permettent pas de relier la requête finale à la requête d' authentification,
- une deuxième partie m rassemblant des éléments aveuglés variables d'un accès à un autre, telles que la date de la requête ou l'identifiant de requête, et
- une troisième partie m* comprenant les éléments aveuglés invariants d'un accès à un autre, à savoir alias de l'utilisateur, e.g. m*=hs.
Ce message d'authentification msg peut ainsi consister en la concaténation de ces trois parties telles que msg = M II m II m*. 4) Lors d'une sous-étape 205 d'aveuglement, l'utilisateur U aveugle alors la deuxième partie m en calculant un premier élément aveuglé c tel que c = h1 H (m)h4 r et aveugle la troisième partie m* en calculant un deuxième élément aveuglé c* tel que c* = hsh4 r .
Ces deux éléments aveuglés vont permettre la signature par le fournisseur d'identités IdP sans que celui-ci n'ait accès aux deux parties m et m*.
5) Ensuite, lors d'une sous-étape 207 de calcul de preuves de connaissance, l'utilisateur U calcule une première preuve V de connaissance de la représentation (H(m), r) du premier élément aveuglé c en bases (h!, h4). L'utilisateur calcule également une deuxième preuve V* de connaissance de la représentation (s, r*) du deuxième élément aveuglé c* en bases (h, h4).
6) Une fois tous ces éléments obtenus, l'utilisateur U envoie au fournisseur d'identités IdP la première partie M du message msg, les premier et deuxième éléments aveuglés c et c*, ainsi que leurs preuves respectives de connaissance V et V* (sous-étape d'envoi 209).
Cet envoi peut avantageusement s'accompagner de authentification de l'utilisateur auprès du fournisseur d'identités IdP, selon une méthode choisie par ce dernier, pour les besoins de la signature aveugle aussi bien que pour la fédération d'identités, dans la mesure où le fournisseur d'identités IdP a pour rôle d'authentifier l'utilisateur U.
A l'issue de cette étape, le fournisseur d'identités IdP peut associer, dans sa base de fédération, alias aveuglé c* de l'utilisateur U chez le fournisseur de services SP à un compte local user@idp de l'utilisateur chez le fournisseur d'identités IdP.
7) Après réception des éléments M, c, c*,V et V*, le fournisseur d'identités IdP calcule une valeur d'engagement C" contenant des engagements sur M, m, m ainsi qu'une valeur dite de randomisation r*+r. Pour ce faire, le fournisseur d'identités IdP choisit aléatoirement une valeur w et calcule la valeur d'engagement C" telle que C" = cc h2 H(m)h3 w dans G (sous-étape de calcul
211). Il est avantageux d'utiliser ici une valeur aléatoire w afin de renforcer la sécurité du processus. 8) Une fois la valeur d'engagement C" calculée, une sous-étape 213 d'obtention d'une signature partielle S sur cette valeur d'engagement C" a lieu. Cette signature partielle S est obtenue en utilisant un processus de signature SIGN avec extensions de l'engagement C" telle que décrit, par exemple, dans « A client-side approach for privacy-preserving identity fédération » de S. Canard et al.
1
Par exemple, cette signature S peut être calculée telle que S = (gjC) 7 "* , avec k choisi aléatoirement dans Z p .
La signature de l'engagement C" correspond alors au triplet (S, w, k).
9) Une fois la signature (S, w, k) de l'engagement C" obtenue, le fournisseur d'identités IdP envoie cette signature (S, w, k) de l'engagement C" à l'utilisateur U lors d'une sous-étape 215 d'envoi de signature d'engagement.
10) Après réception de cette signature (S, w, k) de l'engagement C", l'utilisateur U peut composer une signature σ telle que σ = (S, w, k, r*+r) (sous-étape 217 d'obtention de la signature σ).
11) Peut alors s'ensuivre une sous-étape 219 de vérification de cette signature finale.
Une telle vérification peut être faite en vérifiant que la relation
C = m * h1 fl (m)h2 H(m)h3 wh +r est vérifiée.
Cette vérification peut en outre comporter la vérification de l'équation suivante : (2) e(S, t - g2 i ) = e(g1 , g2 ) - e(m* , g2 ) - e(h1 , g2 )/i(m) - e(h2 , g2 )/i (m) - e(h 3 , g2 )w - e(h1 , g2 )r
12) A l'issue de cette étape 219, l'utilisateur U dispose donc d'une signature σ telle que σ = (S, w, k, r*+r) de son message msg tel que msg = (M, m, m*), ainsi que de ce message msg en tant que tel.
Il ne peut cependant pas transmettre au fournisseur de services SP la signature σ en tant que telle sans révéler l'identité du fournisseur d'identités IdP. Il ne peut pas non plus lui envoyer la clé publique t, pourtant nécessaire à la vérification de cette signature, car cela reviendrait également à révéler l'identité du fournisseur d'identités IdP.
13) Afin de conserver l'anonymat du fournisseur d'identités IdP, l'utilisateur U produit alors une preuve W de connaissance de la signature σ, sans révéler les éléments (S, w, k, r*+r) de cette signature proprement dite, tout en révélant le message msg = (M, m, m*).
Cette preuve W de connaissance sert également à prouver la connaissance de la clé publique t et du certificat de validité de la signature K, sans révéler ces deux valeurs.
La preuve W de connaissance peut ainsi être calculée telle que :
W = POK(r, t, σ : κ = SIGNAC (t) Λ σ = SIGNIdP (m * ||m||M))
Le calcul de cette preuve W de connaissance peut se dérouler de la façon suivante (sous- étape de calcul 221) :
- une première variable masquée associée à la clé publique t est calculée à partir de la clé publique t comme suit :
Ct = tzv' et Ct = gv' zw' , où vt et wt sont des valeurs aléatoires ;
- une deuxième variable masquée associée à l'élément A du certificat κ est calculée à partir de cet élément A comme suit :
CA = AzVAt et CA = gVA zWA , où vA et wA sont des valeurs aléatoires ;
- une troisième variable masquée associée à la signature partielle S appartenant à la signature σ est calculée à partir de cette signature partielle S comme suit :
Cs = SzVst et Cs = g Vs zWs , où vs et ws sont des valeurs aléatoires ;
- les trois autres variables masquées suivantes sont é alement calculées :
Figure imgf000014_0001
Parmi ces trois variables masquées supplémentaires, la quatrième variable masquée C" est associée à la variable A du certificat κ (et dépend de celle-ci), et la cinquième variable masquée Cg ainsi que la sixième variable masquée Cg sont associées à la signature partielle S (et dépendent de celles-ci).
La preuve de connaissance W comprend alors au moins les six variables masquées Ct, Cs,
CA, Ca , Cg , Cg' telles que calculées précédemment.
14) Une fois calculée, la preuve W de connaissance est alors envoyée par l'utilisateur U au fournisseur de services SP, lors d'une étape 223 de transmission de preuve de connaissance.
Ainsi, le fournisseur de services SP ne reçoit pas directement la clé publique t, le certificat κ et la signature σ, ce qui ne lui permet pas de retrouver l'identité du fournisseur d'identités IdP. Cependant, les variables masquées reçues, associées à l'un de ces trois éléments, permettent de vérifier la connaissance de ces trois éléments par l'utilisateur.
L'envoi de cette preuve de connaissance W s'accompagne de l'envoi du message d'authentification msg. La partie m* de ce message, à savoir l'alias de l'utilisateur U, peut alors être associé à un compte local user@sp dans une base de clients du fournisseur de services, ce qui permet la fédération d'identités entre les comptes locaux du fournisseur d'identités IdP et du fournisseur de services SP. La fédération est gérée par l'utilisateur U afin de préserver l'anonymat de celui-ci auprès de ces deux entités.
15) Ainsi, suite à la réception de la preuve W de connaissance, la vérification de la preuve de connaissance W est effectuée, lors d'une sous-étape 225 de vérification, par le fournisseur de services.
Cette vérification de la preuve de connaissance peut comprendre la vérification des équations (1) et (2) telles que définies précédemment.
Avec les variables masquées appartenant à la preuve de connaissance reçue par le fournisseur de services SP, les équations (1) et (2) précédentes peuvent être reformulées respectivement sous la forme des équations (3) et (4) suivantes : (3) e(CA , capk ^2 a) = e(^1 ^2 ) - e(Ct , ^2 ) - e(z^2 )-v' - e(z, capk)v* - e(z, g2 )m*
(4) e(S, t ^2 i ) = e(Cs , Ct ) - e(Cs , ^2 )2i - e(Cs , z)-v' · e(z,Ct)-v- e(z^2 )"2^ - , ζ)ν'ν'
La vérification de la preuve de connaissance consiste alors à vérifier l'équation (5) suivante : W = POK(vt,wt,vA,wt,avA,awA,vs,ws,vsk,wsk, vsvt,wsvt,a,w,r *+r,k : CT =gv'zw' ACa = gv-z WA' ACs =gVszWs Λ
Q = g AazwAa Agk = gvskzwsk Agvt = gvsvtzwstvt Λ
e(CA,capk)e(CA -g2)a =e(gl,g2)e(Ct,g2)e(z,g2)-v'e(z,capk)VAe(z,g2)aVA' Λ e^g^-e^g^-e^g^ -e(h2,g2)H(m) -e(h3,g2)w - ^Υ^ = e(Cs,Ct)e(Cs,g2)2ke(Cs,z)-v'e(z,Ct)-Vse(z,g2)-2^e(z,z)v^)
16) Si cette preuve de connaissance est bien vérifiée, le fournisseur de services SP donne alors accès (sous-étape 227 d'accès au service) à l'utilisateur au service requis.
La fédération d'identités 200 précédemment décrite se déroule lors du premier accès de l'utilisateur au fournisseur de services SP, c'est-à-dire lors de l'envoi d'une première requête d'accès de l'utilisateur au fournisseur de services SP. Lorsque le même utilisateur soumet ultérieurement une nouvelle requête d'accès au même fournisseur de services SP, son identité aura déjà été fédérée et une étape ultérieure d' authentification 300 aura alors lieu, pour chaque envoi d'une nouvelle requête d'accès au fournisseur de services, au moyen des alias déjà fédérés.
Une telle étape ultérieure d' authentification est relativement similaire à la fédération d'identités décrite ci-avant.
Elle diffère cependant de celle-ci en ce que l'utilisateur U doit envoyer au fournisseur de services SP, pendant chaque étape ultérieure d' authentification, le même alias m* que celui qui a été validé pendant la fédération d'identités, afin de permettre au fournisseur de services SP de retrouver l'identité de l'utilisateur U associée à cet alias m* dans sa base de clients
Ici, l'utilisateur U n'a pas besoin de prouver qu'il utilise, au cours de la génération de la preuve de connaissance, le même alias m* que dans l'étape préliminaire de fédération d'identités. En effet, si l'utilisateur U ne suit pas le protocole d' authentification décrit ci-avant, par exemple en utilisant un alias différent de m*, il ne pourra pas être authentifié par le fournisseur de services SP puisque ce dernier ne reconnaîtra pas l'alias qu'il avait précédemment reçu.
Dans un mode de réalisation avantageux, une nouvelle preuve de connaissance W est calculée à chaque étape ultérieure d' authentification de l'utilisateur U auprès du fournisseur de services SP. Cette nouvelle preuve de connaissance est différente des preuves de connaissance calculée(s) lors de l'étape de fédération d'identités 200 et des étapes précédentes d' authentification 300, afin d'assurer l'intraçabilité du fournisseur de services SP par le fournisseur d'identités IdP.
En effet, si la même preuve de connaissance est utilisée lors de plusieurs phases d' authentification ultérieures, le fournisseur d'identités IdP peut faire le lien avec les informations recueillies lors de l'étape préliminaire de fédération d'identités. Pour obtenir une preuve de connaissance différente à chaque étape ultérieure d' authentification 300, les valeurs aléatoires r et r* (voire les deux) peuvent être choisies pour être différentes. La figure 4 illustre les sous-étapes constituant une telle étape d' authentification ultérieure
300. Sur cette figure 4 sont illustrées les sous-étapes 301 à 327, respectivement similaires aux sous- étapes 201 à 227 de l'étape de fédération d'identités 200 décrite précédemment. Une telle étape d' authentification ultérieure 300 se déroule de la façon suivante : 1) L'utilisateur U requiert l'accès à un service du fournisseur de services SP, au moyen d'une requête d'accès REQi(SERV) (sous-étape 301 d'envoi d'une requête d'accès).
2) Suite à la réception de cette requête d'accès REQi(SERV), le fournisseur de services SP envoie une requête d' authentification ultérieure REQi(AUTH) signée afin que l'utilisateur U entame les démarches pour s'authentifier à nouveau (sous-étape 303 d'envoi d'une requête d ' authentification) .
3) Après réception de cette requête d'authentification, l'utilisateur U construit un message d' authentification ultérieure msgi> (sous-étape 304 de construction de message d'authentification) comprenant une première partie Mj rassemblant des éléments non-aveuglés, une deuxième partie η¾ rassemblant des éléments aveuglés variables d'un accès à un autre, et une troisième partie m* comprenant les éléments aveuglés invariants d'un accès à un autre, à savoir alias de l'utilisateur.
Ce message d'authentification ultérieure msgi peut ainsi consister en la concaténation de ces trois parties telles que msgi = Mi II mj II m*.
4) Lors d'une sous-étape 305 d'aveuglement, l'utilisateur U aveugle alors la deuxième partie mj en calculant un premier élément aveuglé tel que c; = h1 H(m)h4 ri et aveugle la troisième partie m* en calculant un deuxième élément aveuglé * tel que c; * = hsh4 r' .
Ces deux éléments aveuglés vont permettre la signature par le fournisseur d'identités IdP sans que celui-ci n'ait accès aux deux parties m et m*.
Les valeurs aléatoires et sont ici avantageusement choisies pour être différentes respectivement des valeurs aléatoires r et r* choisies durant la fédération d'identités ainsi que des valeurs aléatoires et qui ont pu être choisies lors d'éventuelles étapes d'authentification précédentes, dans le but de conserver l'intraçabilité du fournisseur de services SP. 5) Ensuite, lors d'une sous-étape 307 de calcul de preuves de connaissance, l'utilisateur U calcule une première preuve Vj de connaissance du premier élément aveuglé en bases (h!, h4), ainsi qu'une deuxième preuve Vj* de connaissance du deuxième élément aveuglé c* en bases (h, h4), similairement à ce qui est fait à l'étape 207.
6) Une fois tous ces éléments obtenus, l'utilisateur U envoie au fournisseur d'identités IdP la première partie Mj du message msgi, les premier et deuxième éléments aveuglés Cj et (¼*, ainsi que leurs preuves respectives de connaissance Vj et Vj* (sous-étape d'envoi 309). 7) Après réception des éléments Mj, q, Cj*,Vi et Vj*, le fournisseur d'identités IdP calcule une valeur d'engagement Ci" contenant des engagements sur Mj, η¾, m* ainsi qu'une valeur dite de randomisation Γί*+Γί, similairement à l'étape 211 (sous-étape de calcul 311).
8) Une fois la valeur d'engagement Q" calculée, une sous-étape 313 d'obtention d'une signature partielle Si sur cette valeur d'engagement Ci" a lieu, similairement à l'étape 213. La signature de l'engagement Ci" ainsi obtenue correspond alors au triplet (Si, Wj, ¾).
9) Une fois la signature (Si, Wj, ¾) de l'engagement Q" obtenue, le fournisseur d'identités IdP envoie cette signature (Si, Wj, ¾) à l'utilisateur U lors d'une sous-étape 315 d'envoi de signature d'engagement.
10) Après réception de cette signature (Si, Wj, ¾) de l'engagement Q" , l'utilisateur U peut composer une nouvelle signature Oj telle que Oj = (Si, Wj, ¾, ri +ri) (sous-étape 317 d'obtention de la signature σ).
11) Peut alors s'ensuivre une sous-étape 319 de vérification de cette nouvelle signature ai5 similaire à l'étape 219 de la fédération d'identités.
12) A l'issue de cette étape 319, l'utilisateur U dispose donc d'une nouvelle signature σί telle que σί = (Si, Wj, ¾, ri +ri) de son message msgi tel que msgi = (Mj, η¾, m*), ainsi que de ce message
Figure imgf000018_0001
13) Afin de conserver l'anonymat du fournisseur d'identités IdP, l'utilisateur U produit alors une nouvelle preuve Wj de connaissance de la signature ¾ sans révéler les éléments (Si, Wj, ¾, ri +ri) de cette nouvelle signature proprement dite, tout en révélant le message msgi = ( j, η¾, m*).
Cette nouvelle preuve Wj de connaissance sert également à prouver la connaissance de la clé publique t et du certificat de validité de la signature κ, sans révéler ces deux valeurs. La nouvelle preuve Wj de connaissance est calculée similairement à l'étape 221 de la fédération d'identités (sous-étape de calcul 321) : 14) Une fois calculée, la nouvelle preuve Wj de connaissance est alors envoyée par l'utilisateur U au fournisseur de services SP, lors d'une étape 323 de transmission de nouvelle preuve de connaissance.
Ainsi, le fournisseur de services SP ne reçoit pas directement la clé publique t, le certificat κ et la signature σ, ce qui ne lui permet pas de retrouver l'identité du fournisseur d'identités IdP.
En outre, le fournisseur de services SP reçoit une nouvelle preuve Wj de connaissance, différente de la preuve W de connaissance utilisée lors de la fédération d'identités ainsi que des preuves de connaissance Wi,...Wn utilisées lors des éventuelles étapes précédentes d'authentification, ce qui garantit l'intraçabilité du fournisseur de services SP. 15) Suite à la réception de la nouvelle preuve Wj de connaissance, la vérification de cette nouvelle preuve Wj de connaissance est alors effectuée, lors d'une sous-étape 325 de vérification similaire à l'étape 225 décrite ci-avant.
Dans un mode de réalisation avantageux, il n'est pas nécessaire d'avoir recours au fournisseur d'identités IdP pendant l'étape ultérieure d'authentification. L'authentification de l'utilisateur U peut être rendue possible par la connaissance du logarithme discret s de alias m' dans la base h.
Dans ce mode de réalisation avantageux, l'utilisateur U complète la nouvelle preuve de connaissance Wj avec la preuve de connaissance du logarithme discret s vérifiant m*=hs.
Ceci peut être fait en remplaçant l'élément e(m*,g2) par e(h,g2)s dans l'équation (5).
Le fournisseur de services SP vérifie alors cette preuve de connaissance du logarithme discret s par l'utilisateur U et donne l'accès à ses services si cette vérification est positive.
Avec les modes de réalisation décrits précédemment, l'anonymat du fournisseur d'identités IdP auprès du fournisseur de services SP est garanti, ce qui permet de renforcer l'anonymat entre ces deux entités.
Cependant, l'inverse n'est pas forcément vrai dans la mesure où, dans l'exemple de message d'authentification décrit précédemment au cours de la fédération d'identités, l'identité du fournisseur de services SP est comprise dans la partie M non aveuglé du message d'authentification. Le fournisseur d'identités IdP a donc accès à l'identité du fournisseur de services SP et peut obtenir ainsi à partir de sa base clients (ou base de fédération) une information sur les centres d'intérêt de l'utilisateur U. Aussi, dans un mode de réalisation particulièrement avantageux, l'identité du fournisseur de services SP est placée dans la partie aveuglée variable m du message d'authentification, au cours de l'étape 200 de fédération d'identités ainsi qu'au cours des éventuelles étapes 300 d'authentification ultérieures, afin de garantir l'anonymat du fournisseur de services SP auprès du fournisseur d'identités IdP, ce qui permet de renforcer encore plus l'anonymat entre ces deux entités.
Dans ce mode de réalisation particulièrement avantageux, le fournisseur de services SP signe la requête d'authentification avec une signature de groupe avant d'envoyer cette requête à l'utilisateur U, lors des sous-étapes 203 et 303, afin de rester anonyme vis-à-vis du fournisseur d'identités IdP.
Une telle signature de groupe est décrite par exemple dans les articles « A practical and provably secure coalition-résistant group signature scheme » de Ateniese et al., et « Short group signatures » de Boneh et al.
Dans la mesure où il peut être plus avantageux que l'utilisateur U prouve que la même identité SP est utilisée à chaque fois, un mode particulier de réalisation peut alors consister à ce que l'identité du fournisseur de services SP soit placée dans la partie aveuglée invariante m* (en supplément de alias de l'utilisateur) plutôt que dans la partie aveuglée variable m du message d' authentification.
Bien entendu, l'invention n'est pas limitée aux exemples de réalisation ci-dessus décrits et représentés, à partir desquels on pourra prévoir d'autres modes et d'autres formes de réalisation, sans pour autant sortir du cadre de l'invention.
Ainsi, les termes « utilisateur », « fournisseur de services », « fournisseur d'identités » et « autorité de certification » employés précédemment recouvre les entités matérielles utilisées respectivement par un utilisateur, un fournisseur de services, un fournisseur d'identités et une autorité de certification.
De telles entités matérielles peuvent prendre la forme d'un ordinateur ou d'un serveur aptes à effectuer les opérations décrites précédemment, que ce soit en termes de calcul ou de génération de données aléatoires.
Lorsque l'envoi (respectivement la réception) d'un message ou d'une requête par l'une de ces entités matérielles est indiqué ci-avant, cela signifie que cette entité matérielle dispose d'une interface matérielle de transmission (respectivement de réception) utilisant des moyens classiques de transfert de données, par câble ou sans fil par exemple, qui ne seront pas décrits plus en détail ici mais qui sont connus de l'art.

Claims

Revendications
1. Procédé d' authentification d'un utilisateur (U) auprès d'au moins un fournisseur de services (SP), ledit procédé comprenant l'envoi (223), par l'utilisateur au fournisseur de services, d'une première preuve de connaissance (W) d'un certificat de validité (κ) d'une clé publique (t) associée à une clé secrète (y) utilisée par un fournisseur d'identités (IdP) pour signer une première requête d' authentification de l'utilisateur et la vérification (225) de cette preuve de connaissance par le fournisseur de services.
2. Procédé d' authentification selon la revendication 1, caractérisé en ce que l'envoi (223) et la vérification (225) de la première preuve de connaissance (W) ont lieu durant une étape de fédération d'identités (200) qui comprend, en outre :
- l'envoi (209) au fournisseur d'identités (IdP) d'un alias aveuglé (c*) calculé (205) à partir d'un alias (m*) de l'utilisateur (U) ;
- le calcul (221) par l'utilisateur (U) de la première preuve de connaissance (W) à partir d'une signature partielle (S) calculée (213) par le fournisseur d'identités (IdP) à partir de l'alias aveuglé (c*) et de la clé secrète (y);
- l'envoi (223) au fournisseur de services (SP) de l'alias (m*) de l'utilisateur avec la première preuve de connaissance (W).
3. Procédé d' authentification selon la revendication 2, caractérisé en ce que ladite première preuve de connaissance (W) est calculée en outre à partir de la clé publique (t) et d'au moins une partie du certificat de validité (κ).
4. Procédé d' authentification selon la revendication 3, caractérisé en ce que ladite première preuve de connaissance (W) comprend au moins une première valeur masquée (Ct) calculée à partir de la clé publique (t), une deuxième valeur masquée (CA) calculée à partir d'au moins une partie du certificat de validité (κ) et une troisième valeur masquée (Cs) calculée à partir de la signature partielle (S).
5. Procédé d' authentification selon l'une des revendications 1 à 4, caractérisé par une étape préliminaire d'enregistrement (100), préalable à la fédération d'identités, du fournisseur d'identités auprès d'une autorité de certification (CA) comprenant l'envoi (111) par l'autorité de certification au fournisseur d'identités du certificat de validité (κ) calculé (109) à partir d'au moins un engagement (C) envoyé (105) par le fournisseur d'identités.
6. Procédé d' authentification selon la revendication 5, caractérisé en ce que l'engagement (C) envoyé par le fournisseur d'identités est un engagement sur un premier élément (y') choisi aléatoirement par le fournisseur d'identités.
7. Procédé d' authentification selon la revendication 6, caractérisé en ce que la clé secrète (y) utilisée par le fournisseur d'identités comprend le premier élément (y') choisi aléatoirement par le fournisseur d'identités (IdP) ainsi qu'un deuxième élément (y") choisi aléatoirement par l'autorité de certification (CA).
8. Procédé d' authentification selon l'une des revendications précédentes, caractérisé en ce que, lors de l'étape de fédération d'identités (200), la requête d' authentification comprend au moins une partie aveuglée (m, m*) par l'utilisateur (U), une desdites au moins une partie aveuglée comprenant l'identité du fournisseur de services (SP).
9. Procédé d' authentification selon l'une des revendications précédentes, ledit procédé comprenant au moins une étape ultérieure d' authentification (300) et étant caractérisé en ce que chaque étape ultérieure d' authentification comprend l'envoi (323) d'une nouvelle preuve de connaissance (Wj) obtenue (321) à partir d'une signature partielle (Si) calculée (313) par le fournisseur d'identités (IdP) à partir d'un nouvel alias aveuglé ((¾*) et de la clé secrète (y), suivi de la vérification (325) de ladite nouvelle preuve de connaissance par le fournisseur de services.
10. Procédé d' authentification selon la revendication précédente, caractérisé en ce que, pour chaque étape ultérieure d' authentification (300), la nouvelle preuve de connaissance (Wj) est calculée (321) de sorte à être différente de la première preuve de connaissance (W) calculée lors de la fédération d'identités et, si le procédé comprend plusieurs étapes ultérieures d' authentification (300), des nouvelles preuves de connaissance (Wj) calculées lors des autres étapes ultérieures d' authentification.
11. Procédé d' authentification selon la revendication précédente, caractérisé en ce que la première preuve de connaissance (W) est calculée (221) en fonction d'une première et une deuxième variables aléatoires (r,r*) et la nouvelle preuve de connaissance (Wj) est calculée (321) en fonction d'une première et une deuxième variables aléatoires ultérieures (ΐί,ΐί*), lesdites première et deuxième variables aléatoires ultérieures ( ,Γί*) étant choisies pour être différentes desdites première et deuxième variables aléatoires (r,r*) et, si le procédé comprend plusieurs étapes ultérieures d' authentification (300), des première et deuxième variables aléatoires ultérieures
Figure imgf000022_0001
choisies lors des autres étapes ultérieures d' authentification.
12. Procédé d' authentification selon l'une des revendications 9 à 11, dans lequel un message d'authentification comprenant un alias aveuglé ((¾*) de l'utilisateur est envoyé au fournisseur de services à chaque étape ultérieure d'authentification (300), caractérisé en ce que chaque étape ultérieure d'authentification (300) comprend l'aveuglement (305) de alias (m*) de l'utilisateur de sorte que alias aveuglé obtenu (q*) soit différent de alias aveuglé (c*) obtenu lors de l'étape de fédération d'identités (200) et, si le procédé comprend plusieurs étapes ultérieures d'authentification (300), des autres alias aveuglés ((¾*) obtenus lors des autres étapes ultérieures d' authentification.
13. Procédé d'authentification selon la revendication précédente, caractérisé en ce que l'alias aveuglé (c*) obtenu lors de l'étape de fédération d'identités (200) est calculé (205) en fonction de l'alias (m*) de l'utilisateur et d'une variable aléatoire (r*) et l'alias aveuglé ((¾*) obtenu lors d'une étape ultérieure d'authentification (300) est calculé (305) en fonction de l'alias (m*) de l'utilisateur et d'une variable aléatoire ultérieure ¾*), ladite variable aléatoire ultérieure ¾*) étant choisie pour être différente de ladite variable aléatoires (r*) et, si le procédé comprend plusieurs étapes ultérieures d'authentification (300), des variables aléatoires ultérieures fc*) choisies lors des autres étapes ultérieures d'authentification.
14. Système d'authentification à anonymat renforcé comprenant au moins un utilisateur (U), au moins un fournisseur de services (SP), un fournisseur d'identités (IdP) et une autorité de certification (CA), caractérisé en ce que le système est apte à mettre en œuvre le procédé d'authentification selon l'une des revendications 1 à 13 lorsqu'un desdits au moins un utilisateur requiert un service auprès d'un desdits au moins un fournisseur de services.
15. Programme d'ordinateur, téléchargeable via un réseau de télécommunication et/ou stocké dans une mémoire d'une unité centrale et/ou stocké sur un support mémoire destiné à coopérer avec une unité centrale, caractérisé pour mettre en œuvre un procédé selon l'une quelconque des revendications 1 à 13.
PCT/FR2011/051441 2010-06-30 2011-06-23 Procede d'authentification permettant de renforcer l'anonymat entre un fournisseur d'identites et un fournisseur de services WO2012001272A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1002784 2010-06-30
FR1002784A FR2962286A1 (fr) 2010-06-30 2010-06-30 Procede d'authentification permettant de renforcer l'anonymat entre un fournisseur d'identites et un fournisseur de services

Publications (1)

Publication Number Publication Date
WO2012001272A1 true WO2012001272A1 (fr) 2012-01-05

Family

ID=43431164

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2011/051441 WO2012001272A1 (fr) 2010-06-30 2011-06-23 Procede d'authentification permettant de renforcer l'anonymat entre un fournisseur d'identites et un fournisseur de services

Country Status (2)

Country Link
FR (1) FR2962286A1 (fr)
WO (1) WO2012001272A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113545004A (zh) * 2019-01-09 2021-10-22 皇家飞利浦有限公司 具有减少攻击面的认证系统

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008113951A2 (fr) 2007-02-28 2008-09-25 France Telecom Procede d'authentification unique d'un utilisateur aupres de fournisseurs de service

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008113951A2 (fr) 2007-02-28 2008-09-25 France Telecom Procede d'authentification unique d'un utilisateur aupres de fournisseurs de service

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
CANARD, SÉBASTIEN ET AL: "A client-side approach for privacy-preserving identity federation", SPRINGER NETHERLANDS, 1 December 2009 (2009-12-01), pages 269 - 295, XP002617625, Retrieved from the Internet <URL:http://dx.doi.org/10.1007/s12394-009-0024-4> [retrieved on 20110118], DOI: 10.1007/s12394-009-0024-4 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113545004A (zh) * 2019-01-09 2021-10-22 皇家飞利浦有限公司 具有减少攻击面的认证系统

Also Published As

Publication number Publication date
FR2962286A1 (fr) 2012-01-06

Similar Documents

Publication Publication Date Title
EP2116000B1 (fr) Procéée d&#39;authentification unique d&#39;un utilisateur auprès de fournisseurs de service
EP2656538B1 (fr) Accès anonyme a un service au moyen de certificats agrégés
EP2441207B1 (fr) Procédé cryptographique d&#39;authentification anonyme et d&#39;identification séparée d&#39;un utilisateur
EP2514166B1 (fr) Accès a un réseau de distribution de contenu numérique
WO2004047362A1 (fr) Procede et systeme avec authentification, anonymat revocable et non repudiation
CA2377626A1 (fr) Procede et dispositif de paiement electronique
WO2011117486A1 (fr) Infrastructure non hierarchique de gestion de bi-cles de securite de personnes physiques
US20130138953A1 (en) Combining multiple digital certificates
CA2895189C (fr) Signature de groupe utilisant un pseudonyme
EP1282288A1 (fr) Procédé et dispositif d&#39;authentification
EP1400056B1 (fr) Procede d&#39;authentification cryptographique
EP2220812A2 (fr) Procedé d&#39;authentification d&#39;un utilisateur
WO2012001272A1 (fr) Procede d&#39;authentification permettant de renforcer l&#39;anonymat entre un fournisseur d&#39;identites et un fournisseur de services
EP2056565A1 (fr) Procédé d&#39;authentification d&#39;un utilisateur accédant à un serveur distant à partir d&#39;un ordinateur
WO2021122186A1 (fr) Procédé et dispositif de contrôle d&#39;accès anonyme à une plateforme collaborative d&#39;anonymisation
EP3063898B1 (fr) Signature à pseudonyme pour carte à puce
FR3007929A1 (fr) Procede d&#39;authentification d&#39;un utilisateur d&#39;un terminal mobile
WO2021198606A1 (fr) Procede et dispositif d&#39;authentification d&#39;un utilisateur aupres d&#39;une application
WO2011027071A1 (fr) Procédé cryptographique d&#39;abonnement anonyme a un service
EP3672193A1 (fr) Procédé et système d&#39;authentification d&#39;un terminal client par un serveur cible, par triangulation via un serveur d&#39;authentification
FR3118382A1 (fr) Procédé et dispositif permettant un accès autorisé et authentifié pour des identités fédérées
WO2017089710A1 (fr) Procédé de distribution de droits sur un service et plateforme de service
WO2008081151A2 (fr) Procede de signature de liste anonyme et correlable

Legal Events

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

Ref document number: 11736428

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11736428

Country of ref document: EP

Kind code of ref document: A1