WO2008081150A2 - Procede et systeme d'autorisation d'acces a un serveur - Google Patents

Procede et systeme d'autorisation d'acces a un serveur Download PDF

Info

Publication number
WO2008081150A2
WO2008081150A2 PCT/FR2007/052567 FR2007052567W WO2008081150A2 WO 2008081150 A2 WO2008081150 A2 WO 2008081150A2 FR 2007052567 W FR2007052567 W FR 2007052567W WO 2008081150 A2 WO2008081150 A2 WO 2008081150A2
Authority
WO
WIPO (PCT)
Prior art keywords
certificate
message
server
authenticator
received
Prior art date
Application number
PCT/FR2007/052567
Other languages
English (en)
Other versions
WO2008081150A3 (fr
Inventor
Laurent Frisch
David Arditti
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
Priority to EP07871980A priority Critical patent/EP2115657A2/fr
Publication of WO2008081150A2 publication Critical patent/WO2008081150A2/fr
Publication of WO2008081150A3 publication Critical patent/WO2008081150A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates

Definitions

  • the present invention relates to the authorization of access to a server.
  • an applicant when an applicant wants to access a server, he must first authenticate to give proof of his identity. This authentication is generally performed using a couple (identifier, password) that the applicant communicates to the server, along with other data, when registering with this server and creating his account. The server then stores the couple (identifier, password) and the data provided in a database. Each time the applicant wants to access his account, this couple is again asked. The server is then able to see the legitimacy of the applicant and to remove an intruder, depending on the correspondence between the couple stored and the couple entered.
  • a couple identifier, password
  • password means a string of characters chosen by the applicant, this string of characters not necessarily forming a word having a meaning: it may be a sentence or a sequence of characters without any meaning.
  • the requestor must repeat the data communication operation for each server with which he wishes to register, by manually entering this data, which is tedious, or by extracting these data from a database. , which relies on unreliable techniques and is dependent on the equipment used. It is also possible to transmit the data of the applicant from a first server, from which it is registered, to a second server. However, this requires that both servers use the same protocol. In addition, this implies the development of commercial agreements between servers in pairs, which is too complex to be implemented on a large scale.
  • the password provided by the applicant can be easily discovered, including attacking the server database. This can be done simply by sending a deliberately erroneous request to the server, in particular if the database of the server is not protected, which is for example the case for a server that is not critical (providing a news site, for example ). The consequences of such attacks can be very serious, even in the case of a less critical server, because it is common for an applicant to use the same password for several services, some of which contain confidential data (online banking, for example). example).
  • the certification authority creates a certificate, which contains a public key specific to the applicant and a signature from the certification authority, and provides the applicant with the certificate and a certificate private key associated with the public key;
  • the requestor generates a first fingerprint of the request using a hash function, and encrypts the fingerprint using an asymmetric encryption function associated with the private key, to obtain a signature of the applicant;
  • the browser includes in the header of the request the certificate and signature of the applicant and sends the request to the server;
  • the server verifies the validity of the certificate, in particular the signature of the certification authority, and extracts the public key from the certificate;
  • the server decrypts the signature of the applicant using the asymmetric encryption function associated with the public key, generates a second fingerprint of the request using the hash function and compares the first and second fingerprints.
  • the present invention provides an alternative to this method, allowing access authorization as safe but easier to implement.
  • An object of the invention is a method for authorizing access to a server, characterized in that it comprises the following steps: a step of creation by an authority of at least one authenticator of an applicant by processing a at least one password string using a cryptographic function; a step of creating a message from said authenticator, followed by a step of signing said message by the authority and a step of creating a certificate comprising the message and the signature; a step of receiving a chain and a certificate by said server;
  • the server therefore compares a data (authenticator or authenticator treated) guaranteed by a competent authority, thanks to the principle of certificate, and data (chain or processed chain) from the applicant. If these two data are identical, the server is assured of the legitimacy of the applicant.
  • the method according to the invention allows secure authentication of the applicant, because the password thereof is not necessarily stored on a database specific to a server, the risks of attacking this password being then diminished.
  • an attacker wants to access an applicant's account, he can not, even if he knows his password, because he does not have the associated credential.
  • the invention also allows authentication that is easy to initialize for the applicant who, after requesting the assignment of an authenticator associated with a password of his choice with the authority, is only required to transmit to the server the certificate and a string identical to the password string to access the service.
  • the cryptographic function is a hash function.
  • the server then processes the received string using the hash function, to have two comparable data in its possession.
  • a hash function is a function that is difficult to reverse. An attacker who has an authenticator in his possession would therefore not be easily able to recover the password, even if he has the hash function with which the processing was performed.
  • This Embodiment thus makes it possible to provide additional security during the authentication.
  • such a function is not intended to be reserved for the use of a single entity and can therefore be transmitted to an infinite number of servers, the same authenticator (and therefore also the same password) then allowing Applicant authentication on all servers that have access to the hash function.
  • This embodiment therefore allows universal authentication of the applicant and is convenient for the applicant who can memorize a single password for authentication with any server.
  • the cryptographic function is asymmetrically encrypted and associated with a public key specific to the server.
  • the server processes the authenticated credential by means of a private key associated with the public key.
  • the two keys (public and private) used for asymmetric encryption are mathematically related but the knowledge of one does not allow to deduce the other.
  • the second embodiment processes the password so as to obtain a personalized authenticator to a single server or group of servers, having only the private key for decrypting the authenticator.
  • this method makes it possible to control the servers with which the applicant is able to authenticate, which may for example constitute a parental control, in case of use of a single terminal by several members of a family.
  • the authority implements: the creation step for obtaining at least two distinct credentials from the same password string using respective cryptographic functions; and
  • a step of concatenating the authenticators the step of creating the message being performed from the concatenated authenticators.
  • the message creation step is also performed from an identifier of said requestor.
  • the method comprises a step of creating an account associated with the identifier.
  • the creation of a separate account by a specific action of the applicant on each server from which he wishes to register is superfluous.
  • the invention allows the instant creation of an account of the applicant on each server. This mode realization alleviates the architecture of the server that does not need to manage a database "users" heavy and permanent, the accounts can be created at the time of authentication of the applicant and then deleted when it is disconnected.
  • the message creation step is further performed from at least one data provided by the applicant or the authority, and the method includes a step of incorporating said at least one data into the account.
  • This data may be personal data (address, telephone number, etc.) or data concerning the preferences of the applicant at certain parameters (display, etc.) or the service as such.
  • the account is complete without a manual entry is required on the side of the applicant.
  • the server can identify the usual needs of the applicant for a faster service thereof.
  • Another object of the invention is a system for authorizing access to a server, comprising, on the one hand, an authority comprising means for creating a message, means for signing the message and means for creating a certificate comprising the message and the signature, and, secondly, a server comprising means for verifying a signature of a certificate received to verify that it has been created by the authority and means processing, characterized in that the authority further comprises means for creating at least one authenticator by processing at least one password string using a cryptographic function, the means for creating the message being able to create the message from the authenticator, and in that the server processing means are cryptographic processing means of an element constituted by the received string or respectively by an authenticator extracted from the received certificate, the server further comprising means for comparing the processed element with the authenticator extracted from the received certificate or respectively with the received string to verify that this authenticator results from the processing of the received string with the aid of said cryptographic function.
  • Another object of the invention is a method for certifying at least one password string, characterized in that it comprises the following steps implemented by an authority:
  • Another object of the invention is a certification device, comprising means for creating a message, means for signing the message and means for creating a certificate comprising the message and the signature, characterized in that it further comprises means for creating at least one authenticator by processing at least one password string using a cryptographic function, the means for creating the message being able to create the message from the authenticator.
  • Another object of the invention is an authentication method, characterized in that it comprises the following steps, implemented by a server:
  • Another object of the invention is an authentication device comprising means for verifying a signature of a certificate to verify that it has been created by a predetermined authority and processing means, characterized in that the processing means are capable of performing a cryptographic processing of an element constituted by a received string or respectively by an authenticator extracted from the received certificate, the device comprising means for comparing the item processed with the authenticator extracted from the received certificate or respectively with the received string to verify that this authenticator results from the processing of the received string using a predetermined cryptographic function.
  • Another subject of the invention is a certificate resulting from a process according to the invention.
  • Another object of the invention is a data carrier, containing a certificate according to the invention.
  • FIG. 1 is a diagram showing a system for authorizing access to a server according to an embodiment of the invention
  • FIG. 2 is a timing diagram representing a method for authorizing access to a server according to a first embodiment of the invention, using the system of Figure 1, in the case where the authorization of access to the server is granted
  • FIG. 3 is a diagram representing an authentication method forming part of an access authorization method according to the first embodiment
  • FIG. 4 is a timing diagram showing a method of authorizing access to a server according to a second embodiment of the invention, using the system of FIG. 1, in the case where the authorization of access to the server is granted.
  • FIG. 1 shows an access authorization system 10 according to one particular embodiment of the invention.
  • This system 10 comprises an applicant 12, an authority 14, as well as service provider servers 16i and 16 2 , the various elements of the system being interconnected via a telecommunications network 18, for example an Internet network. .
  • the applicant 12 is defined in the application as a set comprising a conventional terminal (such as a computer, a mobile phone, etc.) and a user of this terminal.
  • a terminal 12 comprises storage means 20 comprising a volatile memory type EEPROM, interface means 22, comprising a screen and a keyboard, and transmission / reception means 24, including a messaging software and allowing him to communicate with the other elements 14, 16i, 16 2 of the system 10.
  • the authority 14 is a server forming a certification authority belonging to a certification hierarchy, notably to a public key infrastructure (PKI), this infrastructure possibly comprising other elements not represented in this figure. , such as a registration authority.
  • PKI public key infrastructure
  • the role of the public key infrastructure is to ensure the provision of a certificate and the guarantee of the authenticity of this certificate, and the authority 14 must therefore implement a certification policy describing the measures that may be taken by the authority 14, in particular to verify the data provided by the applicant 12.
  • Authority 14 comprises storage means 40 and transmission / reception means 42 of conventional type. It also includes means 44 for obtaining an authenticator from a string of characters, using a cryptographic function, these means 44 including software means, such as cryptography software, and computing means, such as a processor, for executing the software means.
  • the authority 14 also comprises conventional means 46 for creating a certificate, including means 48 of creating a message and means 49 for signing the message, including inter alia cryptographic software.
  • Each server 16i, 16 2 is a server from which the requestor can authenticate and create an account.
  • each server 16 2 comprises means 6O 1, 6O 2 and data storage means 62 1 62 s 2 transmission / reception of conventional type. It also includes means 64i 64 2 verification of the validity of a certificate, these means comprising software means, including cryptography software, and calculation means for the execution of software means.
  • each server 16 2 also includes means 66i, 66 2 for processing one of a chain and an authenticator, said means comprising a cryptographic software, and means 68 1 68 s 2 Comparison of element with the other element, which include software means. It also comprises means 70i, 70 2 conventional creation of an account associated with an identifier of the applicant 12.
  • the access authorization method 100 can be divided into two methods: a method of certifying by the authority 14 a password string provided by the applicant 12 and a method 120 of authenticating the applicant 12 with the server 16 1 .
  • the authentication method 120 is shown in FIG. 2 only in the case where the applicant 12 obtains the access authorization to the server 16i, whereas, in FIG. 3, the authentication method 120 is represented in its entirety. .
  • the authentication method 120 can not be completed if the certification process has not been performed beforehand, but it is not necessary to carry out the certification process before each authentication. .
  • the method of certification includes a first step 130 of requesting registration of the applicant 12 from the authority 14. This step is performed remotely using the transmission / reception means 24 and can be triggered by selection. on an Internet page of a link of the authority 14 by the applicant 12, using the interface means 22.
  • the step 130 triggers a step 132 of issuing a form to the applicant 12 by the authority 14, using the transmission / reception means 42. This form allows the applicant 12 to disclose data to the authority 14 in a format understood by this authority 14.
  • the applicant 12 fills out the form, for example by manual input using the interface means 22, and transmits the completed form to the authority 14 during a step 136, performed using the applicant's transmitting / receiving means 24.
  • the form completed by the applicant 12 includes identifier and password chosen by the applicant 12, as well as possibly personal data such as an address or telephone number of the user.
  • the method then comprises a step 138, implemented by the authority 14, for verifying the data provided followed, if these data proved to be accurate, of a step 139 of registering the applicant 12 with the authority 14.
  • the authority stores the data provided by the applicant 12 in a database B 1 stored in the storage means 40. It should be noted that this database is particularly protected to avoid intrusions.
  • the method 1 10 then comprises a step 140 for extracting the password string from the database B 1 , followed by a step 142 of creating, from this retrieved string, an authenticator of the applicant 12
  • This step is performed using the means 44, by applying a hash function H, stored in the storage means 40 of the authority, to the password string.
  • the hash function is for example of type MD5, CHA-1, or CHA-256.
  • the method 1 then comprises a step 144 for creating a message comprising the identifier, the authenticator, as well as possibly other data, such as those provided by the applicant 12 during the step 134 or the data provided. by authority 14, such as a deadline for validity.
  • the inclusion of the identifier is optional; It will conveniently enable a service provider to associate this identifier with an account created for the user.
  • the format of the message may be X509v3 format, which is a format containing a public key field, this field being used in this case to host the authenticator.
  • This step 144 is implemented by the means 48 of the authority 14 and is followed by a step 145 of signing the message, using the means 49 of the authority 14.
  • the signature step 145 comprises obtaining an imprint of the message using a hash function H ', stored in the means 40 of the authority 14, and then encrypting this imprint using an asymmetric encryption function, for example an RSA type algorithm (Rivest, Shamir, Adleman), associated with a private key Cp R14 specific to the authority 14, also stored in the storage means 40.
  • an RSA type algorithm for example an RSA type algorithm (Rivest, Shamir, Adleman)
  • the method then comprises a step 146 for creating a certificate C using means 46 of the authority 14.
  • the authority 14 collects the message and its signature in a single file, called certificate.
  • This certificate is of course stored in the storage means 40 of the authority 14.
  • the certification method then comprises a step 148 for issuing the certificate C to the applicant 12, carried out using the transmission / reception means 42 and using the secure transmission mode SSL / TLS ( Secure Sockets Layer / Transport Layer Security).
  • SSL / TLS Secure Sockets Layer / Transport Layer Security
  • This step is followed by a step 149 of storing the certificate C in the storage means 20 of the applicant 12, marking the end of the certification process 1 10.
  • the method may include an additional step to verify that the new password provided in step 134 is different from the old password, to improve the security of the access authorization.
  • This method 120 includes a first step 150 requesting registration by the applicant 12 to the server 16 1 performed using the transmission / reception means 24 and triggered for example by clicking on the link of a web page of the server, using the interface means 22.
  • This step 150 triggers a step 152 d transmitting from the server 16i to the requesting party 12 an authentication page and a certificate request.
  • a step 154 the applicant 12 fills the authentication page, providing a string of characters forming his password, for example by manual input, and transmits to the server 16i this string and the certificate C stored in its files. storage means 20.
  • the certificate C is automatically sent to the server, transparently for the user of the applicant 12, when the latter performs an action to trigger the transmission of the channel.
  • This step is performed using the transmission / reception means 24 and using the Secure Sockets Layer / Transport Layer Security (SSL / TLS) secure transmission mode, guaranteeing the security of the certificate and implemented at the same time. using a pair of keys (public and private) specific to the server 16 1 .
  • SSL / TLS Secure Sockets Layer / Transport Layer Security
  • This secure transmission mode is however not an additional constraint specific to the method 120 because it also exists for conventional authentication methods by couple (identifier, password).
  • the server 16i then executes a step 158 of verification of the signature of the certificate C, as well as a step 160 of verification of the expiry date. These steps constitute a step 162 of verification of the certificate C, carried out using the means 64 ! .
  • the step 158 of verification of the signature of the certificate is performed as follows: the server 16i decrypts the signature using the asymmetric encryption function that has allowed the encryption, here RSA, associated with a public key C PUBM authority 14, so as to obtain a first print of the message. The server then encrypts the message of the certificate C using the hash function H 'so as to obtain a second print of the message. If the two prints are identical, the server is guaranteed that the certificate has been created by the authority 14. It should be noted that the public key C PUBM and the hash function H 'are stored in the storage means 6O 1 of the server 16i and could be downloaded by the server 16i, in particular from the authority 14, prior to the initialization of this process or during it.
  • step 160 the authority extracts the expiry date of the message and compares it with the current date, obtained using a timestamp of the server 16i.
  • the certificate C is valid if the expiry date is not exceeded.
  • the certificate is considered valid and the process continues as shown in Figure 2. If at least one of these conditions is not met, the certificate is not valid. valid and the method then comprises, as shown in Figure 3, a step 163 in which the server 16i transmits to the applicant 12 an error message indicating that its certificate is not valid. The process is then returned to step 152.
  • the method comprises a step 164 of processing the password string provided by the applicant 12 using the hash function H stored in the storage means 6O 1 of the server 16i
  • This function is identical to the function by means of which the authority 14 obtained the authenticator and was for example transmitted in advance to the server 16i by the authority 14.
  • the method then comprises a step 165 for extracting the authenticator of the certificate C and a comparison step 166, using the means 68i , the password string processed in the step 164 and the authenticator .
  • the method comprises a test step 168 (indicated in FIG. 3) determining whether the consecutive authentication failures are greater than a number N, equal for example to 3.
  • the method comprises a step 170 of sending a message from the server 16i to the applicant 12, using the means 62 1 p the message indicating that the word of pass is not valid. The method 120 then resumes in step 152. If the number of consecutive failures is greater than N, the method comprises a step 172 of sending a message to the authority 14, this message indicating that the password has been entered incorrectly several times. This makes it possible to indicate to the authority 14 that the password can be compromised and to take the measures adapted and recommended by the certification policy.
  • the method also comprises a step 174 of sending a message from the server 16i to the requesting party 12 indicating that its authentication has failed and that it can no longer authenticate at least temporarily.
  • the method comprises a step 176 of creating an account in the name of the identifier of the applicant 12, using the means 70i. These means make it possible to create in a database B 2 contained in the storage means 6O 1 of the server 16i, the account of the applicant instantaneously, including storing in this database the identifier and the authenticator.
  • the method then comprises a step 178 of incorporation in the account, in particular in the database B 2 , of the data furthermore appearing in the certificate.
  • This step is followed by a step 180 of transmitting to the applicant 12 a message indicating that the authentication is successful and, possibly, a home page specific to the applicant's account. This step marks the end of the authentication process 120, when the access authorization is given.
  • the method comprises a certification method 210 and a method 220 for authenticating the applicant 12 to the server 16 2 .
  • the method 210 of certification includes the steps 230, 232, 234, 236 requesting registration by the applicant 12, providing a form by the authority 14, filling in the form by the applicant 12 and providing the form to the authority 14, respectively identical to the steps 130, 132, 134, 136 previously described.
  • This method also includes a step 238 of verification of the data provided by the applicant 12, a step 239 of registration of the applicant 12 as well as a step 240 of extracting the password of the applicant 12 of the database Bi, respectively identical to the steps 138, 139, 140 described above.
  • step 242 for creating authenticators using means 44.
  • This step comprises a step 243 for creating a first authenticator and a step 244 for creating a second authenticator.
  • Steps 243, 244 are password processing steps provided by the applicant 12 using, respectively, a first and a second cryptographic function.
  • the first cryptographic function is an asymmetric encryption function A (for example of the RSA type), associated with a public key Cpu B iei specific to the first server 16 13, the second cryptographic function being the same function with asymmetric encryption A, but associated with a public key C PUBI 62 specific to the second server 16 2 .
  • the public keys C PU Bi6i, C PU Bi62 are stored in the storage means 40 of the authority 14 and have been downloaded prior to the initialization of the process or during it, respectively from the servers 16 and 15. 16 2 .
  • the method then comprises a step 246 of concatenating the first and second authenticators, followed by a step 248 of creating a message using the means 48, this step being identical to the step 144 previously described.
  • the message created includes the identifier, the concatenation of the authenticators and possibly other data.
  • the method then comprises steps 249 and 250 for signing the message and creating a certificate, identical to the steps 145 and 146 previously described then a step of transmitting to the applicant 12 of the certificate, identical to step 148, marking the end. of the certification process 210.
  • the certificate provided to the applicant 12 at the end of the method 210 only allows to authenticate with the servers 16i and 16 2 because it includes only the authenticators obtained using public keys specific to these servers.
  • the method includes steps 254, 256, 258, 260 for requesting authentication, providing an authentication page, entering a password string and transmitting the password and certificate from the requesting 12 to the server 16 2 . These steps are respectively identical to the steps 150, 152, 154, 156 described above.
  • the server then comprises a step 262 for verifying the validity of the certificate, identical to the step 162 previously described, using the means 66 2 . It also includes, when the validity of the certificate has been verified, extraction steps 268, 270 of the first and second message authenticators. This step is followed by a step 272 of processing the second authenticator using the inverse function of the asymmetric encryption function A, thus associated with the private key C- P m 62 specific to the server 16 2 , stored in the means 6O 2 of the server 16 2 .
  • the method then comprises a comparison step 274, using the means 68 2 , on the one hand, the second authenticator processed and, on the other hand, the password string transmitted by the applicant 12.
  • the second authenticator processed and the string transmitted by the applicant 12 are identical.
  • the method then comprises steps 276, 278, implemented by the means 70 2 ⁇ for creating an account in the name of the identifier of the applicant 12, included in the certificate, and for incorporating the other data of the certificate into this certificate. account, stored in a database B 2 'storage means 6O 2 .
  • the method then comprises a step 280, identical to step 180, marking the end of the authentication method 220.
  • the method according to the invention allows access to a server 16i, 16 2 secure and relatively simple and instant creation of an account of the applicant 12 to the server 16i, 16 2 .
  • the authority 14 does not belong to a public key infrastructure and is a simple server service provider, to which other servers trust. It is also possible, if the authority 14 belongs to a public key infrastructure, that some of the steps of the method 1 10, 210 are performed by the other entities of the infrastructure.
  • the applicant 12 can give the authority 14 several passwords to be certified, that is to say, to be processed and inserted in the same certificate, which is particularly advantageous in the case where the identifier is a shared account among multiple users who do not want to share the same password.
  • the format of the certificate may also be different from the format described: this may include a specific certificate format.
  • the hash function H 'used by the authority 14 to sign the message and the function used H to obtain the authenticator may also be identical.
  • the method comprises an additional step of verifying the existence of the account before the execution of a possible account creation step 176, 276.
  • the authentication method 120, 220 may also include an additional manual entry step, on the requesting party's side 12, of additional data in the applicant's account 12. It is indeed more prudent than some data, such as bank details, do not appear in the certificate C, these data being then requested if necessary at the time of authentication by the server 16i, 16 2 . Additional steps to verify the validity of the certificate may also be provided, including a step to ensure that the certificate C does not belong to the CRL.
  • Steps 130, 132, 134, 136; 230, 232, 234, 236 processes 1 10, 210 may be performed offline by the applicant 12, that is to say, manually by the user wishing to obtain a certificate and then having for example to obtain an appointment you with a physical person during which he will register. This operation can make step 138, 238 of checking easier.
  • steps 163, 168, 170, 172, 174 of method 120 are optional: if the password is wrong, the method can simply be interrupted. It is also possible that the certificate does not include data other than the identifier and the authenticator, the steps 178, 278 of the methods 120, 220 then being optional.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un procédé d'autorisation d'accès à un serveur (161) comprenant les étapes suivantes : une étape (142) de création par une autorité (14) d'un authentifiant par traitement d'une chaîne formant mot de passe à l'aide d'une fonction cryptographique; - une étape (144) de création d'un message à partir dudit authentifiant, suivie d'une étape (145) de signature dudit message par l'autorité et d'une étape de création (146) d'un certificat comprenant le message et la signature; - une étape (154) de réception d'une chaîne et d'un certificat par ledit serveur (I e1); - une étape de vérification (158) d'une signature comprise dans le certificat reçu; une étape (164, 165) de traitement cryptographique d'un élément constitué par la chaîne reçue ou respectivement par un authentifiant extrait du certificat reçu; et - une étape de comparaison (166) de l'élément traité avec l'authentifiant ou la chaîne.

Description

PROCEDE ET SYSTEME D'AUTORISATION D'ACCES A UN SERVEUR
La présente invention concerne l'autorisation d'accès à un serveur.
De façon classique, lorsqu'un requérant souhaite accéder à un serveur, il doit au préalable s'authentifier pour donner une preuve de son identité. Cette authentification est généralement effectuée à l'aide d'un couple (identifiant ; mot de passe) que le requérant communique au serveur, avec d'autres données, lors de son enregistrement auprès de ce serveur et de la création de son compte. Le serveur stocke alors le couple (identifiant ; mot de passe) et les données fournies dans une base de données. Chaque fois que le requérant souhaite accéder à son compte, ce couple lui est à nouveau demandé. Le serveur est alors capable de constater la légitimité du requérant et d'écarter un intrus, en fonction de la correspondance entre le couple stocké et le couple saisi.
On entend par « mot de passe » une chaîne de caractères choisie par le requérant, cette chaîne de caractères ne formant pas obligatoirement un mot ayant un sens : elle peut être une phrase ou une suite de caractères sans signification aucune.
Dans cette configuration, le requérant doit répéter l'opération de communication de données pour chaque serveur auprès duquel il souhaite s'enregistrer, par saisie manuelle de ces données, ce qui est fastidieux, ou par extraction de ces données d'une base de données, ce qui repose sur des techniques peu fiables et est dépendant du matériel utilisé. Il est également possible de transmettre les données du requérant depuis un premier serveur, auprès duquel il est enregistré, vers un second serveur. Toutefois, il faut pour cela que les deux serveurs utilisent le même protocole. En outre, cela implique la mise au point d'accords commerciaux entre les serveurs deux à deux, ce qui est trop complexe pour pouvoir être mis en œuvre à grande échelle.
Par ailleurs, le mot de passe fourni par le requérant peut être facilement découvert, notamment en attaquant la base de données du serveur. Cela peut être effectué simplement en émettant vers le serveur une requête délibérément erronée, en particulier si la base de données du serveur est peu protégée, ce qui est par exemple le cas pour un serveur peu critique (fournissant un site d'actualités, par exemple). Les conséquences de telles attaques peuvent être très graves, même dans le cas d'un serveur peu critique, car il est courant qu'un requérant utilise le même mot de passe pour plusieurs services dont certains comportent des données confidentielles (banque en ligne, par exemple).
Pour protéger les mots de passe, une solution existante est l'attribution à chaque requérant d'un composant matériel qui lui est propre, par exemple une carte à puce, l'authentification du requérant ne pouvant pas être effectuée sans ce composant. Toutefois, cette solution est coûteuse et pose de nombreux problèmes logistiques.
On connaît également, d'après la publication WO 2005/006703, un procédé d'autorisation d'accès à un serveur par authentification cryptographique, permettant une authentification renforcée d'un requérant auprès du serveur. Ce procédé comprend les étapes suivantes :
- le requérant s'enregistre auprès d'une autorité de certification, l'autorité de certification crée un certificat, contenant une clé publique propre au requérant et une signature de l'autorité de certification, et fournit au requérant le certificat ainsi qu'une clé privée, associée à la clé publique ;
- un navigateur du requérant génère un en-tête d'une requête HTTP classique ;
- le requérant génère une première empreinte de la requête à l'aide d'une fonction de hachage, et chiffre l'empreinte à l'aide d'une fonction de chiffrement asymétrique associée à la clé privée, pour obtenir une signature du requérant ;
- le navigateur inclut dans l'en-tête de la requête le certificat et la signature du requérant et émet la requête vers le serveur ;
- le serveur vérifie la validité du certificat, notamment la signature de l'autorité de certification, et extrait la clé publique du certificat ;
- le serveur déchiffre la signature du requérant à l'aide de la fonction à chiffrement asymétrique associée à la clé publique, génère une deuxième empreinte de la requête à l'aide de la fonction de hachage et compare les première et deuxième empreintes.
Si les deux empreintes numériques sont identiques, cela indique au serveur que le requérant est légitime, l'autorité de certification étant garante de cette authentification. Un tel procédé est sûr mais est relativement complexe et lourd à mettre en oeuvre car il demande l'exécution de nombreuses étapes de calcul.
La présente invention fournit une alternative à ce procédé, permettant une autorisation d'accès tout aussi sûre mais plus simple à mettre en œuvre.
Un objet de l'invention est un procédé d'autorisation d'accès à un serveur, caractérisé en ce qu'il comprend les étapes suivantes : une étape de création par une autorité d'au moins un authentifiant d'un requérant par traitement d'au moins une chaîne formant mot de passe à l'aide d'une fonction cryptographique; - une étape de création d'un message à partir dudit authentifiant, suivie d'une étape de signature dudit message par l'autorité et d'une étape de création d'un certificat comprenant le message et la signature ; une étape de réception d'une chaîne et d'un certificat par ledit serveur;
- une étape de vérification par le serveur d'une signature comprise dans le certificat reçu pour vérifier que le certificat a bien été créé par l'autorité;
- une étape de traitement cryptographique par le serveur d'un élément constitué par la chaîne reçue ou respectivement par un authentifiant extrait du certificat reçu; et une étape de comparaison par le serveur de l'élément traité avec l'authentifiant extrait du certificat reçu ou respectivement avec la chaîne reçue pour vérifier que cet authentifiant résulte bien du traitement de la chaîne reçue à l'aide de ladite fonction cryptographique.
Dans le procédé selon l'invention, le serveur compare donc une donnée (authentifiant ou authentifiant traité) garantie par une autorité compétente, grâce au principe de certificat, et une donnée (chaîne ou chaîne traitée) provenant du requérant. Si ces deux données sont identiques, le serveur est assuré de la légitimité du requérant.
Ainsi, le procédé selon l'invention permet une authentification sûre du requérant, car le mot de passe de celui-ci n'est pas nécessairement stocké sur une base de données propre à un serveur, les risques d'attaque de ce mot de passe étant alors diminués. De plus, si un attaquant souhaite accéder au compte d'un requérant, il en est incapable, même s'il connaît son mot de passe, car il ne possède pas l'authentifiant associé.
Par ailleurs, ce procédé nécessite peu de calculs, et évite notamment les calculs habituellement effectués du côté du requérant, ce type de calculs étant en général peu avantageux car ils demandent une puissance très importante. L'invention permet également une authentification facile à initialiser pour le requérant qui, après avoir sollicité l'attribution d'un authentifiant associé à un mot de passe de son choix auprès de l'autorité, est uniquement tenu de transmettre au serveur le certificat et une chaîne identique à la chaîne formant mot de passe pour pouvoir accéder au service.
Dans un premier mode de réalisation, la fonction cryptographique est une fonction de hachage.
Le serveur traite alors la chaîne reçue à l'aide de la fonction de hachage, pour avoir en sa possession deux données comparables. On rappelle qu'une fonction de hachage est une fonction difficilement inversible. Un attaquant qui aurait en sa possession un authentifiant ne serait donc pas facilement apte à retrouver le mot de passe, même s'il dispose de la fonction de hachage à l'aide de laquelle le traitement a été effectué. Ce mode de réalisation permet donc de fournir une sécurité supplémentaire lors de l'authentification. En outre, une telle fonction n'est pas destinée à être réservée à l'usage d'une seule entité et peut donc être transmise à une infinité de serveurs, le même authentifiant (et donc également le même mot de passe) permettant alors l'authentification du requérant sur tous les serveurs ayant accès à la fonction de hachage. Ce mode de réalisation permet donc une authentification universelle du requérant et est pratique pour le requérant qui peut mémoriser un unique mot de passe pour son authentification auprès de tout serveur.
Dans un deuxième mode de réalisation, la fonction cryptographique est à chiffrement asymétrique et associée à une clé publique propre au serveur.
Dans ce cas, le serveur traite l'authentifiant reçu au moyen d'une clé privée associée à la clé publique. On rappelle que les deux clés (publique et privée) utilisées pour le chiffrement asymétrique sont mathématiquement liées mais la connaissance de l'une ne permet pas de déduire l'autre. Le deuxième mode de réalisation traite le mot de passe de façon à obtenir un authentifiant personnalisé à un seul serveur ou groupe de serveurs, possédant seul la clé privée permettant de déchiffrer l'authentifiant. Ainsi, ce procédé permet de contrôler les serveurs auprès desquels le requérant est apte à s'authentifier, ce qui peut par exemple constituer un contrôle parental, en cas d'utilisation d'un unique terminal par plusieurs membres d'une famille.
De façon optionnelle, l'autorité met en œuvre : l'étape de création pour obtenir au moins deux authentifiants distincts à partir de la même chaîne formant mot de passe à l'aide de fonctions cryptographiques respectives ; et
- une étape de concaténation des authentifiants, l'étape de création du message étant effectuée à partir des authentifiants concaténés.
Ainsi, cela permet d'exercer un contrôle sur les serveurs auprès desquels il est possible de s'enregistrer tout en permettant l'accès à un plus grand nombre de serveurs à l'aide d'un même authentifiant. Cela simplifie donc l'utilisation de l'invention par le requérant.
Dans un mode de réalisation particulier, l'étape de création du message est effectuée également à partir d'un identifiant dudit requérant.
Avantageusement, dans ce cas, le procédé comprend une étape de création d'un compte associé à l'identifiant.
Ainsi, la création d'un compte distinct par une action spécifique du requérant sur chaque serveur auprès duquel il souhaite s'enregistrer est superflue. En effet, l'invention permet la création instantanée d'un compte du requérant sur chaque serveur. Ce mode de réalisation permet d'alléger l'architecture du serveur qui n'a pas besoin de gérer une base de données « utilisateurs » lourde et permanente, les comptes pouvant être créés au moment de l'authentification du requérant puis effacés lors de sa déconnexion.
Optionnellement, l'étape de création du message est effectuée en outre à partir d'au moins une donnée fournie par le requérant ou par l'autorité, et le procédé comprend une étape d'incorporation de ladite au moins une donnée dans le compte.
Cette donnée peut être une donnée personnelle (adresse, numéro de téléphone, etc.) ou une donnée concernant les préférences du requérant au niveau de certains paramètres (affichage, etc.) ou du service en tant que tel. Dès l'authentification, le compte est donc complet sans qu'une saisie manuelle soit nécessaire du côté du requérant. En outre, le serveur peut identifier les besoins habituels du requérant pour un service plus rapide de celui-ci.
Un autre objet de l'invention est un système d'autorisation d'accès à un serveur, comportant, d'une part, une autorité comprenant des moyens de création d'un message, des moyens de signature du message et des moyens de création d'un certificat comprenant le message et la signature, et, d'autre part, un serveur comprenant des moyens de vérification d'une signature d'un certificat reçu pour vérifier qu'il a bien été créé par l'autorité et des moyens de traitement, caractérisé en ce que l'autorité comprend en outre des moyens de création d'au moins un authentifiant par traitement d'au moins une chaîne formant mot de passe à l'aide d'une fonction cryptographique, les moyens de création du message étant aptes à créer le message à partir de l'authentifiant, et en ce que les moyens de traitement du serveur sont des moyens de traitement cryptographique d'un élément constitué par la chaîne reçue ou respectivement par un authentifiant extrait du certificat reçu, le serveur comprenant en outre des moyens de comparaison de l'élément traité avec l'authentifiant extrait du certificat reçu ou respectivement avec la chaîne reçue pour vérifier que cet authentifiant résulte bien du traitement de la chaîne reçue à l'aide de ladite fonction cryptographique.
Un autre objet de l'invention est un procédé de certification d'au moins une chaîne formant mot de passe, caractérisé en ce qu'il comprend les étapes suivantes mises en œuvre par une autorité :
- une étape de création d'au moins un authentifiant par traitement de la chaîne à l'aide d'une fonction cryptographique; et
- une étape de création d'un message à partir de l'authentifiant, suivie d'une étape de signature du message par l'autorité et d'une étape de création d'un certificat comprenant le message et la signature. Un autre objet de l'invention est un dispositif de certification, comprenant des moyens de création d'un message, des moyens de signature du message et des moyens de création d'un certificat comprenant le message et la signature, caractérisé en ce qu'il comprend en outre des moyens de création d'au moins un authentifiant par traitement d'au moins une chaîne formant mot de passe à l'aide d'une fonction cryptographique, les moyens de création du message étant aptes à créer le message à partir de l'authentifiant.
Un autre objet de l'invention est un procédé d'authentification, caractérisé en ce qu'il comprend les étapes suivantes, mises en œuvre par un serveur :
- une étape de vérification d'une signature comprise dans un certificat reçu pour vérifier qu'il a bien été créé par une autorité prédéterminée;
- une étape de traitement cryptographique d'un élément constitué par une chaîne reçue ou respectivement par un authentifiant extrait du certificat reçu; et une étape de comparaison de l'élément traité avec l'authentifiant extrait du certificat reçu ou respectivement avec la chaîne reçue pour vérifier que cet authentifiant résulte bien du traitement de la chaîne reçue à l'aide d'une fonction cryptographique prédéterminée.
Un autre objet de l'invention est un dispositif d'authentification comprenant des moyens de vérification d'une signature d'un certificat pour vérifier qu'il a bien été créé par une autorité prédéterminée et des moyens de traitement, caractérisé en ce que les moyens de traitement sont aptes à effectuer un traitement cryptographique d'un élément constitué par une chaîne reçue ou respectivement par un authentifiant extrait du certificat reçu, le dispositif comprenant des moyens de comparaison de l'élément traité avec l'authentifiant extrait du certificat reçu ou respectivement avec la chaîne reçue pour vérifier que cet authentifiant résulte bien du traitement de la chaîne reçue à l'aide d'une fonction cryptographique prédéterminée.
Un autre objet de l'invention est un certificat, résultant d'un procédé selon l'invention.
Enfin, un autre objet de l'invention est un support de données, contenant un certificat selon l'invention.
L'invention sera mieux comprise à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple et faite en se référant aux dessins dans lesquels : la figure 1 est un schéma représentant un système d'autorisation d'accès à un serveur selon un mode de réalisation de l'invention ; la figure 2 est un chronogramme représentant un procédé d'autorisation d'accès à un serveur selon un premier mode de réalisation de l'invention, à l'aide du système de la figure 1 , dans le cas où l'autorisation d'accès au serveur est accordée ; - la figure 3 est un diagramme représentant un procédé d'authentification faisant partie d'un procédé d'autorisation d'accès selon le premier mode de réalisation ; et la figure 4 est un chronogramme représentant un procédé d'autorisation d'accès à un serveur selon un deuxième mode de réalisation de l'invention, à l'aide du système de la figure 1 , dans le cas où l'autorisation d'accès au serveur est accordée.
On a représenté sur la figure 1 un système d'autorisation d'accès 10 selon un mode de réalisation particulier de l'invention. Ce système 10 comprend un requérant 12, une autorité 14, ainsi que des serveurs fournisseurs de services 16i et 162, les différents éléments du système étant reliés entre eux par l'intermédiaire d'un réseau de télécommunications 18, par exemple un réseau Internet.
Le requérant 12 est défini dans la demande comme un ensemble comprenant un terminal classique (tel qu'un ordinateur, un téléphone mobile, etc.) et un utilisateur de ce terminal. Un tel terminal 12 comprend des moyens de stockage 20, comportant une mémoire volatile de type EEPROM, des moyens d'interface 22, comportant un écran et un clavier, et des moyens d'émission/réception 24, comprenant notamment un logiciel de messagerie et lui permettant de communiquer avec les autres éléments 14, 16i , 162 du système 10.
L'autorité 14 est un serveur formant une autorité de certification appartenant à une hiérarchie de certification, notamment à une infrastructure à clé publique (PKI, acronyme anglais de Public Key Infrastructure), cette infrastructure pouvant comprendre d'autres éléments non représentés sur cette figure, tels qu'une autorité d'enregistrement. De façon classique, l'infrastructure à clé publique a pour rôle d'assurer la fourniture d'un certificat et la garantie de l'authenticité de ce certificat et l'autorité 14 doit de ce fait mettre en place une politique de certification décrivant les mesures pouvant être prises par l'autorité 14, notamment pour vérifier les données fournies par le requérant 12.
L'autorité 14 comprend des moyens de stockage 40 et des moyens d'émission/réception 42 de type classique. Elle comprend également des moyens 44 d'obtention d'un authentifiant à partir d'une chaîne de caractères, à l'aide d'une fonction cryptographique, ces moyens 44 comprenant notamment des moyens logiciels, tels qu'un logiciel de cryptographie, et des moyens de calcul, tels qu'un processeur, permettant l'exécution des moyens logiciels. L'autorité 14 comprend également des moyens classiques 46 de création d'un certificat, comprenant notamment des moyens 48 de création d'un message et des moyens 49 de signature du message, incluant entre autres un logiciel de cryptographie.
Chaque serveur 16i, 162 est un serveur auprès duquel le requérant peut s'authentifier et créer un compte. Chaque serveur 16i, 162 comprend des moyens 6O1, 6O2 de stockage de données et des moyens 621 s 622 d'émission/réception de type classique. Il comprend également des moyens 64i 642 de vérification de la validité d'un certificat, ces moyens comprenant des moyens logiciels, notamment un logiciel de cryptographie, ainsi que des moyens de calcul permettant l'exécution des moyens logiciels. Chaque serveur 16i, 162 comprend également des moyens 66i , 662 de traitement d'un élément parmi une chaîne et un authentifiant, ces moyens comprenant un logiciel de cryptographie, et des moyens 681 s 682 de comparaison de l'élément traité avec l'autre élément, lesquels comportent des moyens logiciels. Il comprend également des moyens 70i, 7O2 classiques de création d'un compte associé à un identifiant du requérant 12.
On va maintenant décrire en référence aux figures 2 et 3 un procédé d'autorisation d'accès au serveur 16i selon un premier mode de réalisation de l'invention. Le procédé d'autorisation d'accès 100 peut être divisé en deux procédés: un procédé 1 10 de certification par l'autorité 14 d'une chaîne formant mot de passe fournie par le requérant 12 et un procédé 120 d'authentification du requérant 12 auprès du serveur 161. Le procédé 120 d'authentification est représenté sur la figure 2 uniquement dans le cas où le requérant 12 obtient l'autorisation d'accès au serveur 16i, alors que, sur la figure 3, le procédé d'authentification 120 est représenté dans son intégralité.
Le procédé 120 d'authentification ne peut pas être mené à bien si le procédé 1 10 de certification n'a pas été effectué au préalable, mais il n'est toutefois pas nécessaire d'effectuer le procédé 1 10 de certification avant chaque authentification 120.
Le procédé 1 10 de certification comprend une première étape 130 de demande d'enregistrement du requérant 12 auprès de l'autorité 14. Cette étape est effectuée à distance à l'aide des moyens d'émission/réception 24 et peut être déclenchée par sélection sur une page Internet d'un lien de l'autorité 14 par le requérant 12, à l'aide des moyens d'interface 22. L'étape 130 déclenche une étape 132 d'émission d'un formulaire vers le requérant 12 par l'autorité 14, à l'aide des moyens d'émission/réception 42. Ce formulaire permet au requérant 12 de divulguer des données à l'autorité 14 selon un format compris par cette autorité 14.
Ensuite, lors d'une étape 134, le requérant 12 remplit le formulaire, par exemple par saisie manuelle à l'aide des moyens d'interface 22, et transmet le formulaire rempli à l'autorité 14 lors d'une étape 136, effectuée à l'aide des moyens d'émission/réception 24 du requérant 12. Le formulaire rempli par le requérant 12 comprend notamment un identifiant et un mot de passe choisis par le requérant 12, ainsi qu'éventuellement des données personnelles telles qu'une adresse ou un numéro de téléphone de l'utilisateur.
Le procédé comprend alors une étape 138, mise en œuvre par l'autorité 14, de vérification des données fournies suivie, si ces données se sont révélées exactes, d'une étape 139 d'enregistrement du requérant 12 auprès de l'autorité 14. Lors de cette étape, l'autorité enregistre les données fournies par le requérant 12 dans une base de données B1 stockée dans les moyens de stockage 40. Il est à noter que cette base de données est particulièrement protégée pour éviter les intrusions.
Le procédé 1 10 comprend ensuite une étape d'extraction 140 de la chaîne formant mot de passe de la base de données B1 , suivie d'une étape 142 de création, à partir de cette chaîne extraite, d'un authentifiant du requérant 12. Cette étape est effectuée à l'aide des moyens 44, en appliquant une fonction de hachage H, stockée dans les moyens de stockage 40 de l'autorité, à la chaîne formant mot de passe. La fonction de hachage est par exemple de type MD5, CHA-1 , ou CHA-256.
Le procédé 1 10 comprend ensuite une étape 144 de création d'un message comportant l'identifiant, l'authentifiant, ainsi qu'éventuellement d'autres données, comme celles fournies par le requérant 12 lors de l'étape 134 ou des données fournies par l'autorité 14, telles qu'une date limite de validité. L'inclusion de l'identifiant est optionnelle ; Elle permettra commodément à un fournisseur de service d'associer cet identifiant à un compte crée pour l'utilisateur. Le format du message peut être le format X509v3, qui est un format contenant un champ de clé publique, ce champ étant utilisé en l'espèce pour héberger l'authentifiant. Cette étape 144 est mise en œuvre par les moyens 48 de l'autorité 14 et est suivie par une étape 145 de signature du message, à l'aide des moyens 49 de l'autorité 14.
L'étape 145 de signature comprend l'obtention d'une empreinte du message à l'aide d'une fonction de hachage H', stockée dans les moyens 40 de l'autorité 14, puis le chiffrement de cette empreinte à l'aide d'une fonction de chiffrement asymétrique, par exemple un algorithme de type RSA (Rivest, Shamir, Adleman), associée à une clé privée CpR14 propre à l'autorité 14, également stockée dans les moyens de stockage 40.
Le procédé comprend ensuite une étape 146 de création d'un certificat C à l'aide des moyens 46 de l'autorité 14. Lors de cette étape, l'autorité 14 rassemble le message et sa signature dans un même fichier, appelé certificat. Ce certificat est bien entendu stocké dans les moyens de stockage 40 de l'autorité 14.
Le procédé 1 10 de certification comprend ensuite une étape 148 d'émission du certificat C vers le requérant 12, effectuée à l'aide des moyens d'émission/réception 42 et à l'aide du mode d'émission sécurisée SSL/TLS (Secure Sockets Layer/ Transport Layer Security). Ce mode d'émission sécurisé implique que le certificat C est chiffré par l'autorité 14 à l'aide d'une clé publique propre au requérant 12 avant son émission et déchiffré par le requérant 12 à l'aide de la clé privée associée à la clé publique à la réception.
Cette étape est suivie d'une étape 149 de stockage du certificat C dans les moyens de stockage 20 du requérant 12, marquant la fin du procédé 1 10 de certification.
Une fois ce procédé mis en oeuvre, il n'est pas besoin de le mettre en oeuvre à nouveau tant que le certificat est valable. Il est à noter que lorsque le certificat expire (lorsque la date limite de validité est dépassée), ce procédé doit être renouvelé sans quoi le requérant 12 ne peut plus obtenir l'autorisation d'accès au serveur 16i. Lors de ce renouvellement, le procédé peut comprendre une étape supplémentaire pour vérifier que le nouveau mot de passe fourni lors de l'étape 134 est différent de l'ancien mot de passe, pour améliorer la sécurité de l'autorisation d'accès.
Ensuite, à chaque fois que le requérant 12 souhaite accéder à un serveur, ici le serveur 16i, il initialise le procédé d'authentification 120. Ce procédé 120 comprend une première étape 150 de demande d'enregistrement par le requérant 12 auprès du serveur 161 effectuée à l'aide des moyens d'émission/réception 24 et déclenchée par exemple en cliquant sur le lien d'une page Internet du serveur, à l'aide des moyens d'interface 22. Cette étape 150 déclenche une étape 152 d'émission depuis le serveur 16i vers le requérant 12 d'une page d'authentification et d'une demande de certificat.
Lors d'une étape 154, le requérant 12 remplit la page d'authentification, en fournissant une chaîne de caractères formant son mot de passe, par exemple par saisie manuelle, et transmet au serveur 16i cette chaîne ainsi que le certificat C stocké dans ses moyens de stockage 20. Le certificat C est émis automatiquement vers le serveur, de façon transparente pour l'utilisateur du requérant 12, lorsque celui-ci effectue une action pour déclencher l'émission de la chaîne.
Cette étape est effectuée à l'aide des moyens d'émission/réception 24 et à l'aide du mode d'émission sécurisée SSL/TLS (Secure Sockets Layer/ Transport Layer Security), garantissant la sécurité du certificat et mis en œuvre à l'aide d'une paire de clés (publique et privée) propre au serveur 161. Ce mode d'émission sécurisé n'est toutefois pas une contrainte supplémentaire spécifique au procédé 120 car il existe également pour les procédés d'authentification classiques par couple (identifiant ; mot de passe).
Le serveur 16i exécute ensuite une étape 158 de vérification de la signature du certificat C, ainsi qu'une étape 160 de vérification de la date limite de validité. Ces étapes constituent une étape 162 de vérification du certificat C, effectuée à l'aide des moyens 64! . L'étape 158 de vérification de la signature du certificat est effectuée de la façon suivante : le serveur 16i déchiffre la signature à l'aide de la fonction de chiffrement asymétrique qui a permis le chiffrement, ici RSA, associée à une clé publique CPUBM propre à l'autorité 14, de façon à obtenir une première empreinte du message. Le serveur chiffre ensuite le message du certificat C à l'aide la fonction de hachage H' de façon à obtenir une seconde empreinte du message. Si les deux empreintes sont identiques, le serveur a la garantie que le certificat a bien été créé par l'autorité 14. Il est à noter que la clé publique CPUBM ainsi que la fonction de hachage H' sont stockées dans les moyens de stockage 6O1 du serveur 16i et ont pu être téléchargées par le serveur 16i , notamment à partir de l'autorité 14, préalablement à l'initialisation de ce procédé ou au cours de celui-ci.
Lors de l'étape 160, l'autorité extrait la date limite de validité du message et compare celle-ci avec la date du jour, obtenue à l'aide d'un horodateur du serveur 16i. Le certificat C est valide si la date limite de validité n'est pas dépassée.
Si les deux conditions énoncées ci-dessus sont remplies, le certificat est considéré comme valide et le déroulement du procédé se poursuit comme représenté sur la figure 2. Si au moins une de ces conditions n'est pas remplie, le certificat n'est pas valide et le procédé comprend alors, comme indiqué sur la figure 3, une étape 163 lors de laquelle le serveur 16i transmet au requérant 12 un message d'erreur lui indiquant que son certificat n'est pas valide. Le procédé est alors renvoyé à l'étape 152.
Dans le cas où le certificat est valide, le procédé comprend une étape 164 de traitement de la chaîne formant mot de passe fournie par le requérant 12 à l'aide de la fonction de hachage H stockée dans les moyens de stockage 6O1 du serveur 16i Cette fonction est identique à la fonction à l'aide de laquelle l'autorité 14 a obtenu l'authentifiant et a été par exemple transmise au préalable au serveur 16i par l'autorité 14.
Le procédé comprend ensuite une étape 165 d'extraction de l'authentifiant du certificat C et une étape 166 de comparaison, à l'aide des moyens 68i, de la chaîne formant mot de passe traitée à l'étape 164 et de l'authentifiant.
Si ces deux éléments sont identiques, le procédé se poursuit comme représenté sur la figure 2. Si ce n'est pas le cas, le procédé comprend une étape 168 de test (indiquée sur la figure 3) déterminant si les échecs d'authentification consécutifs sont supérieurs à un nombre N, égal par exemple à 3.
Si le nombre d'échecs consécutifs est inférieur à N, le procédé comprend une étape 170 d'émission d'un message depuis le serveur 16i vers le requérant 12, à l'aide des moyens 621 p le message indiquant que le mot de passe n'est pas valide. Le procédé 120 reprend alors à l'étape 152. Si le nombre d'échecs consécutifs est supérieur à N, le procédé comprend une étape 172 d'émission d'un message vers l'autorité 14, ce message précisant que le mot de passe a été saisi de façon erronée plusieurs fois. Cela permet d'indiquer à l'autorité 14 que le mot de passe peut être compromis et de prendre les mesures adaptées et préconisées par la politique de certification.
En effet, si, suite à l'avertissement du serveur 161 l'autorité 14 soupçonne que le mot de passe est compromis, le certificat peut être placé dans une liste de révocation de certificats (CRL, sigle anglais pour "Certificate Revocation List") stockée dans les moyens 40 de l'autorité 14. Le certificat C n'est alors plus considéré comme valide. Dans ce cas, le procédé comprend également une étape 174 d'émission d'un message depuis le serveur 16i vers le requérant 12 lui indiquant que son authentification a échoué et qu'il ne peut plus s'authentifier au moins provisoirement.
Dans le cas où les deux éléments comparés sont identiques, le procédé comprend une étape 176 de création d'un compte au nom de l'identifiant du requérant 12, à l'aide des moyens 70i. Ces moyens permettent de créer dans une base de données B2 contenue dans les moyens de stockage 6O1 du serveur 16i, le compte du requérant de façon instantanée, en stockant notamment dans cette base de données l'identifiant et l'authentifiant. Le procédé comprend ensuite une étape 178 d'incorporation dans le compte, notamment dans la base de données B2, des données figurant en outre dans le certificat. Cette étape est suivie d'une étape 180 de transmission au requérant 12 d'un message lui indiquant que l'authentification est réussie et, éventuellement, d'une page d'accueil spécifique au compte du requérant. Cette étape marque la fin du procédé d'authentification 120, lorsque l'autorisation d'accès est donnée.
Nous allons maintenant décrire un second mode de réalisation du procédé d'autorisation d'accès selon l'invention, ce procédé 200 étant représenté sur la figure 4. Il est effectué entre le requérant 12, l'autorité 14 et le serveur 162 représentés sur la figure 1 . Le procédé comprend un procédé de certification 210 et un procédé 220 d'authentification du requérant 12 auprès du serveur 162.
Le procédé 210 de certification comprend les étapes 230, 232, 234, 236 de demande d'enregistrement par le requérant 12, de fourniture d'un formulaire par l'autorité 14, de remplissage du formulaire par le requérant 12 et de fourniture du formulaire à l'autorité 14, respectivement identiques aux étapes 130, 132, 134, 136 précédemment décrites.
Ce procédé comprend également une étape 238 de vérification des données fournies par le requérant 12, une étape 239 d'enregistrement du requérant 12 ainsi qu'une étape 240 d'extraction du mot de passe du requérant 12 de la base de données Bi, respectivement identiques aux étapes 138, 139, 140 décrites précédemment.
Ces étapes sont suivies d'une étape 242 de création d'authentifiants, à l'aide des moyens 44. Cette étape comprend une étape 243 de création d'un premier authentifiant et une étape 244 de création d'un second authentifiant.
Les étapes 243, 244 sont des étapes de traitement de la chaîne formant mot de passe fournie par le requérant 12 à l'aide, respectivement, d'une première et d'une seconde fonction cryptographique. La première fonction cryptographique est une fonction à chiffrement asymétrique A (par exemple, de type RSA), associée à une clé publique CpuBiei propre au premier serveur 1613 la seconde fonction cryptographique étant la même fonction à chiffrement asymétrique A, mais associée à une clé publique CPUBI 62 propre au second serveur 162. Les clés publiques CPUBi6i, CPUBi62 Sont stockées dans les moyens de stockage 40 de l'autorité 14 et ont été téléchargées préalablement à l'initialisation du procédé ou au cours de celui-ci, respectivement à partir des serveurs 1615 et 162.
Le procédé comprend ensuite une étape 246 de concaténation des premier et second authentifiants, suivie d'une étape 248 de création d'un message à l'aide des moyens 48, cette étape étant identique à l'étape 144 précédemment décrite. Le message créé comprend l'identifiant, la concaténation des authentifiants et éventuellement d'autres données.
Le procédé comprend ensuite des étapes 249 et 250 de signature du message et de création d'un certificat, identiques aux étapes 145 et 146 précédemment décrites puis une étape de transmission au requérant 12 du certificat, identique à l'étape 148, marquant la fin du procédé de certification 210.
Le certificat fourni au requérant 12 à l'issue du procédé 210 permet uniquement de s'authentifier auprès des serveurs 16i et 162 car il ne comprend que les authentifiants obtenus à l'aide des clés publiques propres à ces serveurs.
Nous allons maintenant décrire le procédé 220 d'authentification du requérant 12 auprès du serveur 162, dans le cas où l'authentification est réussie. Le procédé comprend des étapes 254, 256, 258, 260 de demande d'authentification, de fourniture d'une page d'authentification, de saisie d'une chaîne formant mot de passe et de transmission du mot de passe et du certificat depuis le requérant 12 vers le serveur 162. Ces étapes sont respectivement identiques aux étapes 150, 152, 154, 156 décrites précédemment.
Le serveur comprend ensuite une étape 262 de vérification de la validité du certificat, identique à l'étape 162 précédemment décrite, à l'aide des moyens 662. Il comprend également, lorsque la validité du certificat a été vérifiée, des étapes d'extraction 268, 270 du premier et du second authentifiants du message. Cette étape est suivie d'une étape 272 de traitement du second authentifiant à l'aide de la fonction inverse de la fonction à chiffrement asymétrique A, donc associée à la clé privée C-Pm62 propre au serveur 162, stockée dans les moyens 6O2 du serveur 162.
Le procédé comprend ensuite une étape 274 de comparaison, à l'aide des moyens 682, d'une part, du second authentifiant traité et, d'autre part, de la chaîne formant mot de passe transmise par le requérant 12. Dans le cas représenté sur la figure 4, le second authentifiant traité et la chaîne transmise par le requérant 12 sont identiques.
Le procédé comprend alors des étapes 276, 278, mises en œuvre par les moyens 702ι de création d'un compte au nom de l'identifiant du requérant 12, compris dans le certificat, et d'incorporation des autres données du certificat dans ce compte, stocké dans une base de données B2' des moyens de stockage 6O2. Le procédé comprend ensuite une étape 280, identique à l'étape 180, marquant la fin du procédé d'authentification 220.
Ainsi, le procédé selon l'invention permet un accès à un serveur 16i, 162 sûr et relativement simple et une création instantanée d'un compte du requérant 12 auprès du serveur 16i, 162.
On notera que l'invention ne se limite pas aux modes de réalisation décrits précédemment. En variante, l'autorité 14 n'appartient pas à une infrastructure à clé publique et est un simple serveur fournisseur de services, à qui les autres serveurs font confiance. Il est également possible, si l'autorité 14 appartient à une infrastructure à clé publique, que certaines des étapes du procédé 1 10, 210 soient exécutées par les autres entités de l'infrastructure.
Il est également possible que le requérant 12 donne à l'autorité 14 plusieurs mots de passe à certifier, c'est-à-dire à traiter et à insérer dans le même certificat, ce qui est particulièrement avantageux dans le cas où l'identifiant correspond à un compte partagé entre plusieurs utilisateurs ne souhaitant toutefois pas partager un même mot de passe.
En outre, le format du certificat peut également être différent du format décrit : ce peut notamment être un format de certificat spécifique. La fonction de hachage H' utilisée par l'autorité 14 pour signer le message et la fonction utilisée H pour obtenir l'authentifiant peuvent également être identiques.
De plus, il est envisageable que le serveur 16i, 162 ait déjà en mémoire un compte au nom de l'identifiant. Dans ce cas, le procédé comprend une étape supplémentaire de vérification d'existence du compte avant l'exécution d'une éventuelle étape de création du compte 176, 276.
Le procédé d'authentification 120, 220 peut également comprendre une étape supplémentaire de saisie manuelle, du côté du requérant 12, de données supplémentaires dans le compte associé au requérant 12. Il est en effet plus prudent que certaines données, comme des coordonnées bancaires, ne figurent pas dans le certificat C, ces données étant alors demandées si besoin au moment de l'authentification par le serveur 16i, 162. Des étapes supplémentaires de vérification de la validité du certificat peuvent être également prévues, notamment une étape permettant de s'assurer que le certificat C n'appartient pas à la liste CRL.
Les étapes 130, 132, 134, 136 ; 230, 232, 234, 236 des procédés 1 10, 210 pourront être effectuées hors ligne par le requérant 12, c'est-à-dire de façon manuelle par l'utilisateur souhaitant obtenir un certificat et devant alors par exemple obtenir un rendez- vous avec une personne physique durant lequel il s'enregistrera. Cette opération peut rendre l'étape 138, 238 de vérification plus aisée.
De plus, les étapes 163, 168, 170, 172, 174 du procédé 120 sont optionnelles : si le mot de passe est erroné, le procédé peut simplement être interrompu. Il est également possible que le certificat n'inclue pas de données autres que l'identifiant et l'authentifiant, les étapes 178, 278 des procédés 120, 220 étant alors optionnelles.

Claims

REVENDICATIONS
1. Procédé (100 ; 200) d'autorisation d'accès à un serveur, caractérisé en ce qu'il comprend les étapes suivantes :
- une étape (142 ; 242, 243, 244) de création par une autorité (14) d'au moins un authentifiant d'un requérant (12) par traitement d'au moins une chaîne formant mot de passe à l'aide d'une fonction cryptographique (H ; A); une étape (144 ; 248) de création d'un message à partir dudit authentifiant, suivie d'une étape (145 ; 249) de signature dudit message par l'autorité (14) et d'une étape de création (146 ; 250) d'un certificat (C) comprenant le message et la signature ;
- une étape (154) de réception d'une chaîne et d'un certificat (C) par ledit serveur
Figure imgf000018_0001
- une étape de vérification (158 ; 264) par le serveur (161 ;162) d'une signature comprise dans le certificat reçu (C) pour vérifier que le certificat a bien été créé par l'autorité (14);
- une étape (164, 165 ; 268, 270, 272, 273) de traitement cryptographique par le serveur (161 ; 162) d'un élément constitué par la chaîne reçue ou respectivement par un authentifiant extrait du certificat reçu (C); et
- une étape de comparaison (166 ; 274) par le serveur (16i ; 162) de l'élément traité avec l'authentifiant extrait du certificat reçu ou respectivement avec la chaîne reçue pour vérifier que cet authentifiant résulte bien du traitement de la chaîne reçue à l'aide de ladite fonction cryptographique (H ; A).
2. Procédé selon la revendication précédente, dans lequel la fonction cryptographique est une fonction de hachage (H).
3. Procédé selon la revendication 1 , dans lequel la fonction cryptographique est à chiffrement asymétrique et associée à une clé publique propre au serveur (CPUBi6i,
4. Procédé selon l'une quelconque des revendications précédentes, dans lequel ladite autorité (14) met en œuvre :
- l'étape (242) de création pour obtenir au moins deux authentifiants distincts à partir de la même chaîne formant mot de passe à l'aide de fonctions cryptographiques respectives ; et une étape (246) de concaténation des authentifiants, l'étape de création du message étant effectuée à partir des authentifiants concaténés.
5. Procédé selon l'une quelconque des revendications précédentes, dans lequel l'étape de création du message est effectuée également à partir d'un identifiant dudit requérant (12).
6. Procédé selon la revendication précédente, dans lequel le procédé comprend une étape (176 ; 276) de création d'un compte associé à l'identifiant.
7. Procédé selon la revendication précédente, dans lequel l'étape (144 ; 248) de création du message est effectuée en outre à partir d'au moins une donnée fournie par le requérant (12) ou par l'autorité (14), et le procédé comprend une étape (178 ; 278) d'incorporation de ladite au moins une donnée dans le compte.
8. Système (10) d'autorisation d'accès à un serveur, comportant, d'une part, une autorité (14) comprenant des moyens (48) de création d'un message, des moyens (49) de signature du message et des moyens (46) de création d'un certificat (C) comprenant le message et la signature, et, d'autre part, un serveur (161 ; 162) comprenant des moyens (64i, 642) de vérification d'une signature d'un certificat reçu (C) pour vérifier qu'il a bien été créé par l'autorité (14) et des moyens (661 , 662) de traitement, caractérisé en ce que l'autorité (14) comprend en outre des moyens (44) de création d'au moins un authentifiant par traitement d'au moins une chaîne formant mot de passe à l'aide d'une fonction cryptographique (H ; A), les moyens (48) de création du message étant aptes à créer le message à partir de l'authentifiant, et en ce que les moyens de traitement (661, 662) du serveur (161 ; 162) sont des moyens de traitement cryptographique d'un élément constitué par la chaîne reçue ou respectivement par un authentifiant extrait du certificat reçu (C), le serveur comprenant en outre des moyens (681, 682) de comparaison de l'élément traité avec l'authentifiant extrait du certificat reçu ou respectivement avec la chaîne reçue pour vérifier que cet authentifiant résulte bien du traitement de la chaîne reçue à l'aide de ladite fonction cryptographique (H ; A).
9. Procédé (1 10 ; 210) de certification d'au moins une chaîne formant mot de passe, caractérisé en ce qu'il comprend les étapes suivantes mises en œuvre par une autorité (14) : une étape (142 ; 242, 243, 244) de création d'au moins un authentifiant par traitement de la chaîne à l'aide d'une fonction cryptographique (H ; A) ; et - une étape (144 ; 248) de création d'un message à partir de l'authentifiant, suivie d'une étape (145 ; 249) de signature du message par l'autorité et d'une étape de création (146 ; 250) d'un certificat (C) comprenant le message et la signature.
10. Dispositif de certification (14), comprenant des moyens (48) de création d'un message, des moyens (49) de signature du message et des moyens (46) de création d'un certificat (C) comprenant le message et la signature, caractérisé en ce qu'il comprend en outre des moyens (44) de création d'au moins un authentifiant par traitement d'au moins une chaîne formant mot de passe à l'aide d'une fonction cryptographique, les moyens (48) de création du message étant aptes à créer le message à partir de l'authentifiant.
1 1 . Procédé (120 ; 220) d'authentification, caractérisé en ce qu'il comprend les étapes suivantes, mises en œuvre par un serveur (16i, 162) : une étape de vérification (158 ; 264) d'une signature comprise dans un certificat reçu (C) pour vérifier qu'il a bien été créé par une autorité prédéterminée (14) ;
- une étape (164, 165 ; 268, 270, 272, 273) de traitement cryptographique d'un élément constitué par une chaîne reçue ou respectivement par un authentifiant extrait du certificat reçu (C); et
- une étape (166 ; 274) de comparaison de l'élément traité avec l'authentifiant extrait du certificat reçu ou respectivement avec la chaîne reçue pour vérifier que cet authentifiant résulte bien du traitement de la chaîne reçue à l'aide d'une fonction cryptographique prédéterminée (H ; A).
12. Dispositif (16i, 162) d'authentification comprenant des moyens (64i, 642) de vérification d'une signature d'un certificat (C) pour vérifier qu'il a bien été créé par une autorité prédéterminée (14) et des moyens de traitement (661 , 662), caractérisé en ce que les moyens de traitement (661, 662) sont aptes à effectuer un traitement cryptographique d'un élément constitué par une chaîne reçue ou respectivement par un authentifiant extrait du certificat reçu (C), le dispositif comprenant des moyens (681, 682) de comparaison de l'élément traité avec l'authentifiant extrait du certificat reçu ou respectivement avec la chaîne reçue pour vérifier que cet authentifiant résulte bien du traitement de la chaîne reçue à l'aide d'une fonction cryptographique prédéterminée (H ; A).
13. Certificat, caractérisé en ce qu'il résulte d'un procédé selon l'une quelconque des revendications 1 à 7, 9 ou 1 1 .
14. Support de données (20 ; 40), caractérisé en ce qu'il contient un certificat selon la revendication précédente.
PCT/FR2007/052567 2006-12-28 2007-12-19 Procede et systeme d'autorisation d'acces a un serveur WO2008081150A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP07871980A EP2115657A2 (fr) 2006-12-28 2007-12-19 Procede et systeme d'autorisation d'acces a un serveur

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0655997 2006-12-28
FR0655997 2006-12-28

Publications (2)

Publication Number Publication Date
WO2008081150A2 true WO2008081150A2 (fr) 2008-07-10
WO2008081150A3 WO2008081150A3 (fr) 2008-10-16

Family

ID=38222061

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2007/052567 WO2008081150A2 (fr) 2006-12-28 2007-12-19 Procede et systeme d'autorisation d'acces a un serveur

Country Status (2)

Country Link
EP (1) EP2115657A2 (fr)
WO (1) WO2008081150A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3057973A1 (fr) * 2016-10-25 2018-04-27 Peugeot Citroen Automobiles Sa Procede d'installation d'un certificat dans un calculateur de vehicule, calculateur et systeme associes

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005006703A2 (fr) 2003-07-11 2005-01-20 International Business Machines Corporation Systeme et procede d'authentification de clients dans un environnement client-serveur
US20060005237A1 (en) 2003-01-30 2006-01-05 Hiroshi Kobata Securing computer network communication using a proxy server

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020144108A1 (en) * 2001-03-29 2002-10-03 International Business Machines Corporation Method and system for public-key-based secure authentication to distributed legacy applications

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060005237A1 (en) 2003-01-30 2006-01-05 Hiroshi Kobata Securing computer network communication using a proxy server
WO2005006703A2 (fr) 2003-07-11 2005-01-20 International Business Machines Corporation Systeme et procede d'authentification de clients dans un environnement client-serveur

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3057973A1 (fr) * 2016-10-25 2018-04-27 Peugeot Citroen Automobiles Sa Procede d'installation d'un certificat dans un calculateur de vehicule, calculateur et systeme associes
WO2018078234A1 (fr) * 2016-10-25 2018-05-03 Psa Automobiles Sa Procédé d'installation d'un certificat dans un calculateur de véhicule, calculateur et système associés

Also Published As

Publication number Publication date
EP2115657A2 (fr) 2009-11-11
WO2008081150A3 (fr) 2008-10-16

Similar Documents

Publication Publication Date Title
US9338163B2 (en) Method using a single authentication device to authenticate a user to a service provider among a plurality of service providers and device for performing such a method
EP2345202B1 (fr) Procédé de signature numérique en deux étapes
EP2811708B1 (fr) Système et méthode pour l'authentification d'un utilisateur
EP2614458B1 (fr) Procede d'authentification pour l'acces a un site web
EP1401142A1 (fr) Procede de signature electronique, programme et serveur pour la mise en oeuvre du procede
EP1549011A1 (fr) Procédé et système de communication entre un terminal et au moins un équipment communicant
WO2011138558A2 (fr) Procede d'authentification d'un utilisateur requerant une transaction avec un fournisseur de service
EP2279581A1 (fr) Procede de diffusion securisee de donnees numeriques vers un tiers autorise
US11777743B2 (en) Method for securely providing a personalized electronic identity on a terminal
EP1774699A1 (fr) Procede d'authentification anonyme base sur un algorithme cryptographique de type asymetrique
WO2007012583A1 (fr) Procede de controle de transactions securisees mettant en oeuvre un dispositif physique unique, dispositif physique, systeme, et programme d'ordinateur correspondants
EP2301187A1 (fr) Terminal d'authentification forte d'un utilisateur
WO2017081208A1 (fr) Procede de securisation et d'authentification d'une telecommunication
EP2509025A1 (fr) Procédé d'accès à une ressource protégée d'un dispositif personnel sécurisé
EP2568406B1 (fr) Procédé de mise en oeuvre, a partir d'un terminal, de données cryptographiques d'un utilisateur stockées dans une base de données
WO2003107587A1 (fr) Procede et dispositif d’interface pour echanger de maniere protegee des donnees de contenu en ligne
WO2013034865A1 (fr) Procede d'authentification
WO2008081150A2 (fr) Procede et systeme d'autorisation d'acces a un serveur
EP3899765B1 (fr) Réinitialisation d'un secret applicatif au moyen du terminal
EP2710779A1 (fr) Procede de securisation d'une platforme d'authentification, dispositifs materiels et logiciels correspondants
EP2630746B1 (fr) Procede et systeme d'authentification
WO2023057652A1 (fr) Application de sécurité pour un dispositif informatique, et architecture de sécurité correspondante

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

REEP Request for entry into the european phase

Ref document number: 2007871980

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2007871980

Country of ref document: EP

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

Ref document number: 07871980

Country of ref document: EP

Kind code of ref document: A2