EP2115657A2

EP2115657A2 - Method and system for authorizing access to a server

Info

Publication number: EP2115657A2
Application number: EP07871980A
Authority: EP
Inventors: Laurent Frisch; David Arditti
Original assignee: France Telecom SA
Current assignee: Orange SA
Priority date: 2006-12-28
Filing date: 2007-12-19
Publication date: 2009-11-11
Also published as: WO2008081150A3; WO2008081150A2

Abstract

The invention relates to a method for authorizing access to a server (161) comprising the following steps: a creation step (142) by an authority (14) of an identifier by processing of a string forming a password with the use of a cryptographic function; - a message creating step (144) from the said identifier, followed by a signature step (145) of the said message by the authority and a step for creating a certificate (146) comprising the message and the signature; - a string and certificate reception step (154) by the said server (I e1); a signature verification step (158) comprised in the received certificate; a cryptographic processing step (164, 165) of an element constituted by the received string or respectively by an authenticator extracted for the received certificate; and - a comparison step (166) for the element processed with the authenticator of the string.

Description

METHOD AND SYSTEM FOR AUTHORIZING ACCESS TO A SERVER

The present invention relates to the authorization of access to a server.

Typically, 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.

The term "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.

In this configuration, 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.

In addition, 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).

To protect passwords, an existing solution is the allocation to each applicant of a hardware component of its own, for example a smart card, the authentication of the applicant can not be performed without this component. However, this solution is expensive and poses many logistical problems.

It is also known from publication WO 2005/006703, a method of authorization of access to a server by cryptographic authentication, allowing enhanced authentication of an applicant to the server. This process comprises the following steps:

- the applicant registers with a certification authority, 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;

- a requestor's browser generates a header of a classic HTTP request;

- 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.

If the two digital fingerprints are identical, this indicates to the server that the requestor is legitimate, the certification authority being the guarantor of this authentication. Such a method is safe but is relatively complex and cumbersome to implement because it requires the execution of many calculation steps.

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;

a step of verification by the server of a signature included in the certificate received to verify that the certificate has been created by the authority;

a step of cryptographic processing by the server of an element constituted by the received string or respectively by an authenticator extracted from the received certificate; and a step of comparison by the server of 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.

In the method according to the invention, 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.

Thus, 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. In addition, if 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.

Moreover, this process requires few calculations, and especially avoids the calculations usually performed on the side of the applicant, this type of calculation is generally not very advantageous because they require a very large power. 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.

In a first embodiment, 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. It is recalled that 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. In addition, 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.

In a second embodiment, the cryptographic function is asymmetrically encrypted and associated with a public key specific to the server.

In this case, the server processes the authenticated credential by means of a private key associated with the public key. It is recalled that 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. Thus, 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.

Optionally, 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.

Thus, it allows to exercise control over the servers from which it is possible to register while allowing access to a larger number of servers using the same authenticator. This simplifies the use of the invention by the applicant.

In a particular embodiment, the message creation step is also performed from an identifier of said requestor.

Advantageously, in this case, the method comprises a step of creating an account associated with the identifier.

Thus, the creation of a separate account by a specific action of the applicant on each server from which he wishes to register is superfluous. Indeed, 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.

Optionally, 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. Upon authentication, the account is complete without a manual entry is required on the side of the applicant. In addition, 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:

a step of creating at least one authenticator by processing the string using a cryptographic function; and

a step of creating a message from the authenticator, followed by a step of signing the message by the authority and a step of creating a certificate comprising the message and the signature. 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:

a step of verifying a signature included in a certificate received to verify that it has been created by a predetermined authority;

a step of cryptographic processing of an element constituted by a received string or respectively by an authenticator extracted from the received certificate; and a step of 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 using a predetermined cryptographic function.

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.

Finally, another object of the invention is a data carrier, containing a certificate according to the invention.

The invention will be better understood on reading the description which follows, given solely by way of example and with reference to the drawings in which: 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; and 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 ₂ , 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. Such 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 ₂ 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. Conventionally, 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 ₂ is a server from which the requestor can authenticate and create an account. 16i each server 16 ₂ comprises means 6O _1, 6O ₂ and data storage means 62 ₁ 62 _s ₂ transmission / reception of conventional type. It also includes means 64i 64 ₂ verification of the validity of a certificate, these means comprising software means, including cryptography software, and calculation means for the execution of software means. 16i each server 16 ₂ also includes means _66i, 66 ₂ for processing one of a chain and an authenticator, said means comprising a cryptographic software, and means 68 ₁ 68 _s ₂ Comparison of element with the other element, which include software means. It also comprises means 70i, 70 ₂ conventional creation of an account associated with an identifier of the applicant 12.

A method for authorizing access to the server 16i according to a first embodiment of the invention will now be described with reference to FIGS. 2 and 3. 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 ₁ . 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.

Then, during a step 134, 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. In this step, the authority stores the data provided by the applicant 12 in a database B ₁ 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 ₁ , 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.

The method then comprises a step 146 for creating a certificate C using means 46 of the authority 14. In this step, 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). This secure transmission mode implies that the certificate C is encrypted by the authority 14 using a public key specific to the applicant 12 before it is issued and decrypted by the applicant 12 using the private key associated with the public key at the reception.

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.

Once this process is implemented, there is no need to implement it again as long as the certificate is valid. It should be noted that when the certificate expires (when the expiry date is exceeded), this process must be renewed otherwise the applicant 12 can no longer obtain the access authorization to the server 16i. During this renewal, 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.

Then, each time the applicant 12 wishes to access a server, here the server 16i, it initializes the authentication method 120. This method 120 includes a first step 150 requesting registration by the applicant 12 to the server 16 ₁ 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.

In 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 ₁ . 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 ₁ 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.

In 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.

If both of the above conditions are met, 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.

In the case where the certificate is valid, 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 ₁ 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 .

If these two elements are identical, the process continues as shown in FIG. 2. If this is not the case, 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.

If the number of consecutive failures is less than N, 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.

Indeed, if, following the warning of the server 16 ₁ the authority 14 suspects that the password is compromised, the certificate can be placed in a certificate revocation list (CRL). ) stored in the means 40 of the authority 14. The certificate C is then no longer considered valid. In this case, 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.

In the case where the two elements compared are identical, 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 ₂ contained in the storage means 6O ₁ 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 ₂ , 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.

We will now describe a second embodiment of the access authorization method according to the invention, this method 200 being shown in Figure 4. It is performed between the applicant 12, the authority 14 and the server 16 ₂ represented in Figure 1. The method comprises a certification method 210 and a method 220 for authenticating the applicant 12 to the server 16 ₂ .

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.

These steps are followed by a 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 ₂ . 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 ₂ .

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 ₂ because it includes only the authenticators obtained using public keys specific to these servers.

We will now describe the authentication method 220 of the applicant 12 to the server 16 ₂ , in the case where the authentication is successful. 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 ₂ . 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 ₂ . 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 ₆₂ specific to the server 16 ₂ , stored in the means 6O ₂ of the server 16 ₂ .

The method then comprises a comparison step 274, using the means 68 ₂ , on the one hand, the second authenticator processed and, on the other hand, the password string transmitted by the applicant 12. In the case shown in Figure 4, 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 ₂ 'storage means 6O ₂ . The method then comprises a step 280, identical to step 180, marking the end of the authentication method 220.

Thus, the method according to the invention allows access to a server 16i, 16 ₂ secure and relatively simple and instant creation of an account of the applicant 12 to the server 16i, 16 ₂ .

Note that the invention is not limited to the embodiments described above. Alternatively, 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.

It is also possible for the applicant 12 to 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.

In addition, 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.

In addition, it is conceivable that the server 16i, 16 ₂ already has in memory an account in the name of the identifier. In this case, 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 ₂ . 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.

In addition, 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.

Claims

Method (100; 200) for authorizing access to a server, characterized in that it comprises the following steps:

a step (142, 242, 243, 244) of an authority (14) creating at least one authenticator of an applicant (12) by processing at least one password string with the aid of a cryptographic function (H; A); a step (144; 248) of creating a message from said authenticator, followed by a step (145; 249) of signing said message by the authority (14) and a creation step (146; 250 ) a certificate (C) including the message and the signature;

a step (154) for receiving a string and a certificate (C) by said server

a step of checking (158; 264) by the server (16 ₁ ; 16 ₂ ) of a signature included in the received certificate (C) to verify that the certificate has been created by the authority (14);

a step (164, 165, 268, 270, 272, 273) of cryptographic processing by the server (16 ₁ ; 16 ₂ ) of an element constituted by the received string or by an authenticator extracted from the received certificate (C) ; and

a step of comparison (166; 274) by the server (16i; 16 ₂ ) of the element processed with the authenticator extracted from the received certificate or with the received string respectively to verify that this authenticator results from the processing of the chain received using said cryptographic function (H; A).

2. Method according to the preceding claim, wherein the cryptographic function is a hash function (H).

3. Method according to claim 1, wherein the cryptographic function is asymmetrically encrypted and associated with a public key specific to the server (C _PUB i6i,

The method of any one of the preceding claims, wherein said authority (14) implements:

the creation step (242) for obtaining at least two different authenticators from the same password string using respective cryptographic functions; and a step (246) for concatenating the authenticators, the message creation step being performed from the concatenated authenticators.

5. Method according to any one of the preceding claims, wherein the step of creating the message is also performed from an identifier of said applicant (12).

6. Method according to the preceding claim, wherein the method comprises a step (176; 276) of creating an account associated with the identifier.

7. Method according to the preceding claim, wherein the step (144; 248) of creation of the message is performed further from at least one data provided by the applicant (12) or the authority (14), and the method comprises a step (178; 278) of incorporating said at least one item into the count.

8. System (10) for authorizing access to a server, comprising, on the one hand, an authority (14) comprising means (48) for creating a message, means (49) for signing the message and means (46) for creating a certificate (C) comprising the message and the signature, and, on the other hand a server (16 _1; 16 ₂₎ comprising means (64i, 64 ₂₎ verification of a signature of a received certificate (C) to verify that it has been created by the authority (14) and means (66 ₁ , 66 ₂ ) of processing, characterized in that the authority (14) further comprises means (44) for creating at least one authenticator by processing at least one password string using a cryptographic function (H; A), the means (48) for creating of the message being able to create the message from the authenticator, and in that the processing means (66 ₁ , 66 ₂ ) of the server (16 ₁ ; 16 ₂ ) are means for cryptographic processing of a con element. stitué by the received string or respectively by an authenticator extracted from the received certificate (C), the server further comprising means (68 ₁ , 68 ₂ ) for comparing the item processed with the authenticator extracted from the received certificate or respectively with the received string for verifying that this authenticator results from the processing of the received string with the aid of said cryptographic function (H; AT).

9. Method (1 10; 210) for certifying at least one password string, characterized in that it comprises the following steps implemented by an authority (14): a step (142; 242, 243) 244) for creating at least one authenticator by processing the string using a cryptographic function (H; A); and - a step (144; 248) of creating a message from the authenticator, followed by a step (145; 249) of signing the message by the authority and a creation step (146; 250) of a certificate (C) comprising the message and the signature.

A certification device (14), comprising means (48) for creating a message, means (49) for signing the message and means (46) for creating a certificate (C) comprising the message and the signature, characterized in that it comprises in in addition to means (44) for creating at least one authenticator by processing at least one password string using a cryptographic function, the means (48) for creating the message being able to create the message from the authenticator.

1 1. Authentication method (120; 220), characterized in that it comprises the following steps, implemented by a server (16i, 16 ₂ ): a verification step (158; 264) of a signature included in a certificate received (C) to verify that it has been created by a predetermined authority (14);

a step (164, 165; 268, 270, 272, 273) of cryptographic processing of an element constituted by a received string or respectively by an authenticator extracted from the received certificate (C); and

a step (166; 274) of comparing the processed element with the authenticator extracted from the received certificate or with the received string, respectively, to verify that this authenticator results from the processing of the received string by means of a function predetermined cryptographic (H; A).

12. The device (16i 16 ₂₎ comprising authentication means (64i, 64 ₂₎ for verifying a signature of a certificate (C) to verify that it has been created by a predetermined authority (14) and processing means (66 ₁ , 66 ₂ ), characterized in that the processing means (66 ₁ , 66 ₂ ) are capable of performing a cryptographic processing of an element constituted by a received string or respectively by an authenticator extracted of the received certificate (C), the device comprising means (68 ₁ , 68 ₂ ) for comparing the item processed with the authenticator extracted from the received certificate or with the received string respectively to verify that this authenticator is the result of the processing of the received string using a predetermined cryptographic function (H; A).

13. Certificate, characterized in that it results from a method according to any one of claims 1 to 7, 9 or 1 1.

14. Data carrier (20; 40), characterized in that it contains a certificate according to the preceding claim.