EP2115657A2 - Verfahren und system zur autorisierung des zugriffs auf einen server - Google Patents

Verfahren und system zur autorisierung des zugriffs auf einen server

Info

Publication number
EP2115657A2
EP2115657A2 EP07871980A EP07871980A EP2115657A2 EP 2115657 A2 EP2115657 A2 EP 2115657A2 EP 07871980 A EP07871980 A EP 07871980A EP 07871980 A EP07871980 A EP 07871980A EP 2115657 A2 EP2115657 A2 EP 2115657A2
Authority
EP
European Patent Office
Prior art keywords
certificate
message
server
authenticator
received
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP07871980A
Other languages
English (en)
French (fr)
Inventor
Laurent Frisch
David Arditti
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
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 SA filed Critical France Telecom SA
Publication of EP2115657A2 publication Critical patent/EP2115657A2/de
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • G06F21/33User 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)
EP07871980A 2006-12-28 2007-12-19 Verfahren und system zur autorisierung des zugriffs auf einen server Withdrawn EP2115657A2 (de)

Applications Claiming Priority (2)

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

Publications (1)

Publication Number Publication Date
EP2115657A2 true EP2115657A2 (de) 2009-11-11

Family

ID=38222061

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07871980A Withdrawn EP2115657A2 (de) 2006-12-28 2007-12-19 Verfahren und system zur autorisierung des zugriffs auf einen server

Country Status (2)

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

Families Citing this family (1)

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

Family Cites Families (3)

* 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
US20060005237A1 (en) 2003-01-30 2006-01-05 Hiroshi Kobata Securing computer network communication using a proxy server
DE602004012870T2 (de) 2003-07-11 2009-05-14 International Business Machines Corp. Verfahren und system zur benutzerauthentifizierung in einer benutzer-anbieterumgebung

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2008081150A2 *

Also Published As

Publication number Publication date
WO2008081150A2 (fr) 2008-07-10
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 (de) Digitales signaturverfahren in zwei schritten
EP2811708B1 (de) System und Methode zur Authentifizierung eines Benutzers
EP2614458B1 (de) Authentifizierungsverfahren zum zugang auf eine webseite
EP1401142A1 (de) Verfahren, Programm und Server zur Erzeugung von digitalen Signaturen
EP1549011A1 (de) Kommunikationsverfahren und System zwischen einem Endgerät und mindestens einer Kommunikationsvorrichtung
WO2011138558A2 (fr) Procede d'authentification d'un utilisateur requerant une transaction avec un fournisseur de service
EP2279581A1 (de) Verfahren zum sicheren senden digitaler daten an eine autorisierte drittpartei
US11777743B2 (en) Method for securely providing a personalized electronic identity on a terminal
EP1774699A1 (de) Anonymes authentifizierungsverfahren basierend auf einem asymmetrischen verschlüsselungsalgorithmus
EP1911194A1 (de) Verfahren zur kontrolle sicherer transaktionen anhand eines einzelnen physikalischen geräts, entsprechendes physikalisches gerät, system und computerprogramm
WO2009130088A1 (fr) Terminal d'authentification forte d'un utilisateur
EP3375133A1 (de) Verfahren zur sicherung und authentifizierung einer telekommunikation
EP2509025A1 (de) Zugriffsverfahren auf eine geschützte Quelle einer gesicherten persönlichen Vorrichtung
EP2568406B1 (de) Verfahren zur Verwendung von kryptografischen Daten eines Benutzers, die in einer Datenbank gespeichert sind, von einem Endgerät aus
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 (de) Neuinitialisierung eines anwendungsgeheimnisses über das endgerät
EP2710779A1 (de) Verfahren zur sicherung einer authentifizierungsplattform sowie entsprechende hardware und software
EP2630746B1 (de) Authentifikationsverfahren und -system
WO2023057652A1 (fr) Application de sécurité pour un dispositif informatique, et architecture de sécurité correspondante

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20090709

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR

17Q First examination report despatched

Effective date: 20091210

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20170419