EP1561302A1 - Procede et systeme avec authentification, anonymat revocable et non repudiation - Google Patents

Procede et systeme avec authentification, anonymat revocable et non repudiation

Info

Publication number
EP1561302A1
EP1561302A1 EP03782564A EP03782564A EP1561302A1 EP 1561302 A1 EP1561302 A1 EP 1561302A1 EP 03782564 A EP03782564 A EP 03782564A EP 03782564 A EP03782564 A EP 03782564A EP 1561302 A1 EP1561302 A1 EP 1561302A1
Authority
EP
European Patent Office
Prior art keywords
client
server
token
signature
anonymous
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
EP03782564A
Other languages
German (de)
English (en)
Inventor
Sébastien CANARD
Stéphane GUILLOTEAU
Eric Malville
Jacques Traore
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 EP1561302A1 publication Critical patent/EP1561302A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/383—Anonymous user system
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3255—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using group based signatures, e.g. ring or threshold signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/42—Anonymization, e.g. involving pseudonyms

Definitions

  • the invention relates to the field of security of access to services, in particular to computer resources.
  • the general objective of the invention is to offer a strong and anonymous user authentication service and a fast and economical mechanism for maintaining an authentication session.
  • the invention allows, despite anonymity, to empower users by offering resources the possibility of lifting the anonymity of the user if necessary (in the event of a dispute for example).
  • the invention can find many applications. Those which will be indicated below should not be considered as limiting.
  • the major applications of this invention are electronic auctions or network / community games.
  • the invention is adapted in particular to any application whose purpose is to provide a public place where several users can meet and chat while keeping their anonymity.
  • the invention is particularly relevant for electronic auctions, the aim of which is to reproduce the operating principle of real auctions.
  • Real auctions allow people, gathered in the same room, to bid anonymously. Although their real identity is never revealed, participants cannot retract.
  • the present invention offers the same properties of anonymous authentication and non-repudiation.
  • the present invention offers these properties: it " guarantees the anonymity of the players (the identity of the players is not revealed) while making them responsible (the identity of the players can be revealed if necessary).
  • the general aim of the invention is to propose means allowing 1) to guarantee the anonymity of the customers, 2) to effectively maintain an authentication session and 3) to make the customers accountable.
  • Certain techniques allow a server to authenticate a client. These techniques are generally coupled with a mechanism allowing an authentication session to be maintained between the user and the server.
  • Disposable passwords the principle of single-use passwords - also called disposable passwords or OTP (One-Time Password) - consists of using passwords that can only be used once. Even if the password is stolen, it cannot be reused.
  • this device generally takes the form of a card (eg ActivCard, SecurlD) which calculates the passwords that the user must enter to authenticate. This password is then used to calculate a session key (a secret key) intended to guarantee the confidentiality and integrity of the exchanges.
  • SSL and TLS these are techniques based on certificates and public key (or asymmetric) cryptography algorithms for authentication and secret (or symmetric) cryptography algorithms for session maintenance.
  • a certificate constitutes a digital identity card. He takes the form of a file containing a public key and information about its owner. This information is certified (ie signed) by a trusted authority called the certification authority.
  • a server sends him a challenge (a random numeric value) that the user signs with his private key.
  • the public key allows the server to verify that the user has the private key, the certificate, to know the identity of the user.
  • this authentication phase allows the client and the server to exchange a session key (a secret key) which will allow them to guarantee the confidentiality and integrity of their exchanges.
  • Kerberos this is an SSO (Single Sign-On) mechanism allowing a user to access several resources without having to authenticate several times. It is based on secret key cryptography algorithms.
  • KDC Key Distribution Center
  • KDC Key Distribution Center
  • This token is sent transparently to the target server and allows it to identify / authenticate the user and recover a session key (a secret key) used by the server and the client to guarantee the confidentiality and integrity of their trades.
  • the authentication mechanisms offered by these techniques are intended to verify the real identity of the client. This identity is revealed by the login in the case of disposable passwords, by the certificate in the case of TLS and SSL or by the authentication token in the case of Kerberos.
  • Non-repudiation is not guaranteed: These techniques are based on secret key cryptography algorithms to maintain the authentication session and guarantee the confidentiality and integrity of exchanges. This type of cryptographic algorithm does does not guarantee non-repudiation; The customer can always deny having sent a message.
  • Maintaining the session is costly: maintaining the session is achieved by encrypting or authenticating the messages that the client and the server exchange. The client must, at all times, have means of calculation to maintain the session.
  • pseudonym is the most common approach used by servers currently deployed on the Internet (eg electronic auction sites, gaming sites). This technique is based on an authentication mechanism based on the use of a login (i.e. the pseudonym) and a password. Users generally register with the server by entering a certain amount of personal information and choosing a pseudonym and password which they must then present to authenticate. This approach poses a number of problems:
  • [3] and [4] and used in particular for electronic auctions in article [5]) also offer an anonymous authentication mechanism.
  • the general principle consists, for a client, in registering with a trusted authority, the group manager. Customers registered with this authority belong to the same group and have the means necessary to sign on behalf of the group. Any server has the means to verify a signature. Verification of a signature consists, in fact, of verifying that it has been produced by a member of the group; It does not reveal anything about the member who produced it and therefore does not allow the server to know his identity. Customer anonymity is therefore guaranteed. A server can, however, interrogate the group manager to remove the anonymity of the signatory.
  • This technique therefore responds to the problem of anonymous authentication.
  • it does not include any mechanism allowing an authentication session to be maintained between a client and a server.
  • the server cannot therefore "remember" the identity of the client.
  • the client To maintain authentication, the client must sign each of the messages it transmits to the server and must therefore have the necessary computing resources at all times.
  • the calculations used to produce such signatures are quite substantial and do not allow rapid authentication.
  • An object of the invention is to provide a complete solution to the problem of anonymous authentication and session maintenance.
  • H ⁇ authenticate the Client with the Anonymous Certification Authority on the basis of the means provided in i) and provide means allowing him to authenticate anonymously with a Server, iii) authenticate the Client by the production of '' an anonymous signature and open and maintain an anonymous authentication session with a Server, and selectively allow contact between the Server and the Anonymous Certification Authority to lift the anonymity of the Client on the basis of the signature provided in step iii).
  • Step i) advantageously consists for a User Client of recovering, from the Anonymous Certification Authority forming a trusted third party, the information (a public key and a certificate) enabling him to calculate anonymous signatures. Any server or resource can verify these signatures without revealing the user's real identity. A valid signature guaranteed to the resource or server that he can, if necessary, recover the real identity of the user by questioning the trusted third party.
  • the present invention thus provides a complete and global solution for:
  • the invention is based on strong authentication mechanisms allowing the anonymity of customers to be preserved;
  • the present invention also relates to a system capable of allowing the opening and maintenance of an authentication session guaranteeing non-repudiation, characterized in that it comprises means suitable for the implementation of three phases:. a first phase in which a Client calculates a set of data, formed of a series of tokens, one of which makes it possible to open a session, while the others make it possible to maintain it,. a second phase in which the Client strongly commits to the sequence of tokens after a Server, and
  • the Client has means enabling him to produce a digital signature which is not necessarily anonymous, although preferably it is understood.
  • FIG. 1 represents the general architecture of the relational means involved in the context of the present invention
  • FIG. 2 represents a schematic flow diagram of the method according to the present invention
  • FIG. 6 shows schematically the group signing process
  • FIG. 7 shows schematically the application of the present invention to an electronic auction process
  • FIG. 8 schematizes a preparatory stage for sale and consultation in the context of electronic auctions
  • FIG. 9 schematizes an example of an item sheet made available to a visitor, potential client, within the framework of an auction
  • FIG. 10 schematizes a step for obtaining an anonymous certificate
  • FIG. 11 schematizes the steps of group registration, generation of keys and sending of certificate in this context
  • FIG. 12 shows schematically a step of request for participation with certificate and authorization
  • FIG. 13 schematizes the steps of initialization and then generation of tokens by two respective Customers in the context of auctions
  • FIG. 14 shows schematically a step of participation in an auction
  • FIG. 15 shows schematically the steps of overbidding by token transmission whose index (or "rank") represents the value chosen for the auction
  • FIG. 16 shows schematically a step of processing auction orders
  • FIG. 17 shows schematically the processing of a token received from a Client and the comparison of the value represented by its index with the data previously received
  • FIG. 18 schematizes a stage of conclusion of an auction
  • FIG. 19 diagrams stages of informing the client who wins the auction, the losing clients, the seller and the end of the transaction, and
  • FIG. 20 shows schematically a Client-Server architecture for implementing the method of the present invention.
  • the invention implements three entities in the protocol: Clients C, at least one Anonymous Certification Authority ACA and at least one Server (or "Resource") Se.
  • the invention proposes, on the one hand, an anonymous authentication mechanism based on the use of an anonymous certificate.
  • it proposes an economic and efficient session maintenance mechanism guaranteeing non-repudiation.
  • it offers a global solution combining anonymous authentication mechanisms (eg group signature, anonymous certificate) and the session maintenance mechanism to address the following issues:
  • User anonymity the invention is based on strong authentication mechanisms that preserve user anonymity, not only vis-à-vis other users, but also vis-à-vis servers;
  • the authentication session maintenance mechanism proposed by the invention does not require any calculation on the user side. All the necessary information is calculated beforehand during the authentication phase;
  • Non-repudiation The invention guarantees non-repudiation. On the one hand because at any time, the server can lift the anonymity of a user by interrogating the trusted third party ACA. On the other hand because the server can prove each of the actions of a user.
  • the Anonymous Certification Authority issues anonymous certificates and is adapted and empowered to lift anonymity if necessary.
  • the Server provides services to people C wishing to remain anonymous, this anonymity can be lifted when necessary.
  • a Client will obtain an anonymous certificate for the purpose of authenticate anonymously and then maintain a session with a Server.
  • the method according to the invention in a preferred implementation essentially comprises 4 steps.
  • Step 1 identification.
  • Client C registers with a trusted authority (this authority can be either the Anonymous Certification Authority itself, or a certification authority).
  • This step consists of the user providing personal information (surname, first name, address, etc.).
  • the client can register either online by filling in an electronic form, or by physically moving to a specific location.
  • the trusted authority verifies the identity of the customer and all or part of their personal information, stores this information for future use and provides the Customer with the means (for example a login / password or a certificate) that will allow him to authenticate with the ACA. It should be noted that in the rest of the protocol, the Customer will no longer provide his personal data at any time.
  • Step 2 authentication with the ACA.
  • This step involves the Client and the ACA.
  • the Client authenticates strongly with the ACA (using the means he obtained in step 1).
  • the ACA in turn provides him with the means to produce an anonymous signature. It retains the means of being able to connect the Client at any time (i.e. the natural person it knows using strong authentication) to any signature emanating from it.
  • Step 3 anonymous authentication with the Server.
  • This step involves a Server and a Client. The latter wishes to maintain a session to access the services offered by the Server and must therefore let the latter know that he has authenticated himself strongly with the ACA.
  • the Client wants to remain anonymous vis-à-vis the Server and other potential clients.
  • the goal of this step is to open a session with the Server by making a certain number of calculations so that you can maintain this session very quickly.
  • This step will thus be divided into three phases. The first phase will allow the Client to calculate a set of data (a series of tokens), one of these tokens opening the session while the others will allow it to be maintained.
  • the second phase will allow the Client to strongly commit to this suite of tokens with the Server.
  • the third phase will consist in maintaining the session using this suite.
  • the ACA may require authentication of the Servers who want to offer the anonymity service to their users. For this, the ACA must be able to require authentication of the servers before delivering an anonymous certificate to the user and / or before lifting anonymity.
  • the servers must therefore first submit to a registration phase with the ACA. For this, each server makes a request for affiliation to the ACA which studies the proposal (according to criteria it has established) and decides whether to accept the proposal.
  • the first two phases require a dialogue between the user and the ACA on the one hand (first phase), and between the user and the server on the other hand (second phase). They will therefore typically be performed using a web browser or an application hosted on the client's computer. However, since the sequence of tokens is pre-calculated during the authentication phase, it can be embedded in a portable terminal (mobile phone, PDA, etc.). The user can therefore authenticate with the server using a browser or an application and then maintain the authentication session using another type of terminal.
  • a hash function H has the following properties:
  • the sequence of tokens is therefore (W n , W n - ⁇ , W n - 2 , ..., W ⁇ , Wo). Due to the properties of the hash functions, it is easy, starting from W 0 / to calculate any of the Wj (for i going from 1 to n) while it is impossible in practice to find W 0 from Wj (for i ranging from 1 to n). - • « -
  • the Client uses its anonymous strong authentication means obtained in step 2 to produce an anonymous signature of the Wn initialization token, the signature allowing the server to authenticate this Client (he can check the validity of signing and therefore being convinced of the rights of the client he has in front of him).
  • the Client has thus just opened an anonymous session with the Server. He will be able to maintain this session using the token suite.
  • the token W n is stored by the Server and will be used to check the validity of the other tokens (and therefore of the session).
  • a certain amount of information can be associated with the initialization token (for example, the cash value of a token). This information constitutes the session information and makes it possible to describe the semantics associated with each token. A token will therefore allow the server to find the identity of the sender but also the session information.
  • the Server wants to be sure that he can find the physical identity of the client in front of him, according to the principle defined in the fourth step. In addition, this authentication must be done quickly. For this, the Customer simply transmits, with each new authentication, a token from the list calculated previously: W n - ⁇ , then W n - 2 , W n - 3 , ... To continue the session, the Customer thus transmits the tokens in the order of n - 1 to 0.
  • the Server is able to verify this link: the received Wj token is compared with the tokens of all the clients present in the database.
  • the W k connected to the Wj received it uses the formula: h '(W
  • Step 4 It involves a Server and the Trusted Authority. The first has in his possession a signature which he knows emanates from a Client who has identified himself strongly with the ACA. If he wishes, he can therefore send this signature to the ACA, which has the means to discover the physical identity of the signatory (cf. first step) and to provide this information to the Server. The latter can thus obtain the physical identity of the Client who produced the signature and all of the tokens that he received during his session.
  • a variant consists in ensuring that the Server does not at any time know the identity of the Client. In this case, once the anonymity has been lifted by the ACA, the latter personally contacts the Client involved and thus ends the session in an appropriate manner.
  • the right to produce anonymous signatures has a limited lifespan (for example linked to a single session).
  • the Client will have to authenticate themselves strongly with the ACA at each session (i.e. for each token suite).
  • the number of sessions linked to an engagement is limited in time. Indeed, the sequence of tokens is finished. Once the last token has been sent, the Client must produce a new suite of tokens with the Server and must anonymously sign the initialization token.
  • step 3 can be used alone to effectively open and maintain an authentication session.
  • a Client will be able to authenticate himself strongly with the server (but without anonymity this time) and maintain a session, very quickly, using the series of tokens that he will have previously calculated. This approach also ensures non-repudiation.
  • the first token sent by the Client to the Server is called the initialization token and is used to open the session. It is linked both to the authentication of the Client from a signature and to the information session. Thus, the initialization token fixes by association, in a message sent by the Client to the Server, the proof of authentication and the initialization parameters of the session.
  • the token mechanism is used in the participation phase in a sale.
  • a Client requests participation in the auction by sending a message consisting of the initialization token associated with the parameters of the sale, for example, the item identifier, its current price, and the step value. This message is signed.
  • the Client also transmits, in this participation request, the means for the server to verify the signature (message, public key, certificate ...) and therefore to authenticate the Client, depending on the signature mechanism used. Specifications of the signing mechanism will be described below. If the authentication of the Client by the Server is valid, the initialization token and the data transmitted by the Client, in this participation request, are recorded by the Auction Server.
  • Session maintenance tokens In the case of auctions, if the Server authorizes the Client to participate in the sale after receiving the initialization token, the Client can then bid higher by sending the Server the successive tokens and only the tokens. Indeed, each Client's auction order results in the sending of a token without any other information or signature. From the information recorded with the initialization token, the Server is able to authenticate the order by assigning the token to its owning Client and calculating its value. Thus, each token received by the Server is compared with all of the registered tokens. By dependence between tokens, the token movement received by the Server can only correspond to one token present in the database. The Server finds information on the Client and on the item linked to the received token by matching it with a stored token and only one.
  • the token mechanism can be applied to auctions by establishing calculation rules.
  • the calculation of the index i of the Wi token for overbidding (super price) is based on the current price of the article (maximum price) and the step of the article (step).
  • the Wi token received is compared with the tokens present in the base.
  • the formulas to find the token and calculate its value can be: -
  • Wj price of W k + (I * step)
  • the signature of the initialization token allows the opening of a session and can be carried out, depending on the case, with or without anonymity.
  • the Customer has a private key SK, a public key PK and a certificate (anonymous or not). It uses its private key SK and a cryptographic algorithm (for example RSA, DSA or group signature) to sign a message composed of the initialization token Wn and session information session_data. It thus obtains an S-Sigsk signature (Wn, session_data) which it sends to the Server with the message, its public key PK and the certificate C which links this public key to its own identity.
  • a cryptographic algorithm for example RSA, DSA or group signature
  • FIG. 3 shows schematically the details of the protocol for signing the initialization token.
  • This pseudonym may possibly be the encryption of the real Customer identity accompanied by a hazard.
  • the lifting of anonymity is thus easily done by the ACA which deciphers this pseudonym to obtain the identity of the Client.
  • the ACA remembers the link between the Client and his pseudonym so that he can subsequently lift his anonymity.
  • an anonymous certificate is used to link a pseudonym to a public key. But it can also, depending on the context, contain other information making it possible to limit the scope of the certificate (e.g. server identifier, session identifier, validity date, client's IP address , the authentication context ).
  • the step of signing the initialization token consists for the Customer of using his private key PK (it is therefore an RSA signature).
  • the message consists of the initialization token W1000, the signature S, the public key PK and the certificate linked to the pseudonym AC + Pseudo.
  • the Server therefore opens a session with a client he knows only under a pseudonym. It thus verifies that the Client has authenticated strongly with the ACA using the CA certificate and that the certified public key PK (and belonging to the pseudonym) makes it possible to verify the signature of the initialization token.
  • the lifting of anonymity is implemented when the Server provides the ACA with the certificate (or pseudonym). The ACA can know which Client corresponds to this pseudonym and therefore who produced the signature.
  • Figure 4 shows the details of the anonymous certificate protocols. It should be noted that to obtain an interesting anonymity, it is advisable to change the certificate (and therefore the pair of signature keys) at each session. It is therefore necessary that the Customer connects to the ACA at each session. ⁇ CT ⁇ ⁇
  • the Customer wishes to connect to several servers benefiting from ACA services, at least two options are available to him.
  • Either the ACA provides a single (universal) certificate for all the servers, in which case it is possible to trace the pseudonym of this Client on all the sites (we do not know who he is but we know what he done on each of the servers).
  • Either the ACA provides a certificate per server, in which case the universality of the certificate is lost, but it is then impossible to trace the same client on several servers.
  • Each server provides the Customer with an identifier which is forwarded to the ACA. The latter then knows that he has provided a given certificate for such a server to such a client and therefore will not provide two.
  • Part of the process in accordance with the present invention may resemble a blind certificate with revocable anonymity.
  • a blind signature scheme is a protocol involving two entities: a signatory and a user. It allows the user to obtain the signature of a given message made by the signatory, without the latter learning anything about the message.
  • the blind signature model with revocable anonymity consists of several users, a signatory, a recognized authority, for example a judge, and two protocols:
  • the ACA plays the role of the signatory and the Server plays that of the judge.
  • the Client is the user.
  • the Client creates a public PK - private SK key pair (for example of type RSA). It keeps the private signature key secret and sends the public key PK to the ACA in order to obtain, during a strongly authenticated session, a blind signature BC with revocable anonymity (protocol for obtaining a certificate) of this key (the blind signature corresponds to his anonymous certificate).
  • the ACA remembers the means of lifting the anonymity of this signature.
  • the step of signing the initialization token (token signing protocol) consists for the Customer of using his private key PK to sign (it is therefore an RSA signature).
  • the message consists of the initialization token W1000, the signature S, the public key PK and the anonymous certificate BC.
  • the Server verifies that the Client has authenticated himself strongly with the ACA using the anonymous certificate (he verifies that the BC signature does indeed emanate from the ACA) and that the certified public key PK indeed makes it possible to verify the signature S of the initialization token
  • the lifting of anonymity is implemented when the Server provides the ACA with the anonymous BC certificate.
  • the ACA can know when it produced this signature (protocol for lifting of anonymity) and therefore to whom it is provided.
  • Figure 5 shows the details of the blind certificate certificates with revocable anonymity.
  • the invention can also implement a group signature.
  • a group signature allows members of a group to produce a signature such that the verifier will recognize this signature as having been produced by a member of the group, while ignoring which member it is.
  • a trusted authority has the possibility of lifting this anonymity at any time and therefore of revealing the identity of the signatory.
  • Such signatures are very often "non-correlable": it is impossible to determine whether two signatures were issued by the same person or not.
  • the group is assigned a unique group public key, while each member of this group is assigned a unique identifier and private key.
  • a group member can generate a group signature of a message of their choice, which signature can be verified by any entity using the group public key. Verification only tells this entity that the signature was produced by a member of the group, but does not give it any information on the identifier of the member who signed.
  • the trusted authority has additional information which allows it to find the identifier of this member, and therefore to lift this anonymity at any time (it is said that the authority of trust "opens" the signature). Refer to documents [1], [2], [3] and [4] for group signature diagrams.
  • the ACA plays the role of trusted authority.
  • a Client will register with a group with the ACA by interacting with them in order to obtain a GC member certificate (member registration protocol).
  • the ACA reserves the means to open a signature if necessary.
  • group signing protocol group signing protocol
  • ie S Sig GP (W1000)
  • the signatory is anonymous within the group.
  • the Server has the means to verify that a signature has indeed been issued by a member of the group (group signature verification protocol) but without knowing which member it is.
  • the ACA as a trusted authority, has the means to open the signature (group signature opening protocol) to lift anonymity and disclose the identity of the signatory.
  • Figure 6 shows the details of the group certificate protocols. It should be noted that, due to the anonymity and unreliability properties of group signatures, it is not necessary to register with the group for each session. The fact of being registered with the group makes it possible to make as many group signatures as the Client wishes without, however, someone being able to link two of his signatures. This single certificate can be used with several servers without risk of being able to trace the client. Likewise, a customer with multiple machines will not need to obtain multiple certificates.
  • the application presented here to illustrate the process according to the invention belongs to the field of electronic commerce in the form of Internet auctions.
  • the process offers an innovative solution to secure electronic auctions and allow transactions to be carried out with confidence.
  • the cryptography used in the context of the invention makes it possible to meet the objectives.
  • the information transmitted is unintelligible to persons outside the transaction for reasons of confidentiality.
  • the process ensures non-repudiation to guarantee that the client cannot deny having made an act of overbidding.
  • the process ensures the integrity of the data exchanged.
  • the method makes it possible to ensure the identity of a user by authentication.
  • the process is fast for taking account of auction orders in real time.
  • the characteristic of the tokens used in the process according to the invention is its single use. It can only be used for one and only one auction order, and does not reveal any information about its user. It just checks that the transmitted request belongs to a specific user.
  • a bid order identified by a disposable password is certified to belong to a particular buyer for a single value.
  • the tokens are sent by client C to the auction server Se to bid on a product.
  • the principle is to sign the first token sent to register a client's request to participate.
  • the tokens transmitted for bidding are checked against this first initialization token, in accordance with the process described above.
  • the following tokens represent the bids. For example, if a customer (customer 1) participates in an auction with a starting price of 1000 and a step of 100, he can offer to bid at 1100 by transmitting a token (W999). To bid at 1400 and beat another buyer who rose at 1300, he must reveal the token corresponding to the price of 1400, ie the W996 token.
  • the Anonymous Certification Authority is placed on an anonymity server (SA);
  • the service provider server is here the auction server
  • Client C We also find in this application a certificate server (SC) which provides a certificate for strong authentication.
  • SC certificate server
  • the main functions of the electronic auction system are:
  • the preparatory phase which consists in selling, consulting and obtaining an anonymous certificate
  • the auction phase which consists of requesting and verifying participation in a sale, bidding and verifying bidding in order to acquire an item;
  • the conclusion phase which consists of ending the auction, validating and identifying a winner by lifting anonymity, closing the sale.
  • M.Martin is an art collector, he decides to acquire a work for sale on the auction site. He connects to the site and asks to display the catalog of items for sale. Among the articles, he is particularly interested in a photograph entitled Regards, the starting price of which is 600 euros and sold by M.LeVendeur. He then clicks to obtain the article file, illustrated by way of example in FIG. 9.
  • Constraint Double certification; - Precondition: Strong authentication (step 1 of the process), choose an anonymity server (SA);
  • M.Dupond is always decided to participate in the auction for a work of art whose starting price is 500,000 euros. He wishes to remain anonymous for this sale in order not to reveal his financial means or his interest in the type of work to be sold, and, if he wins the auction, he does not want anyone to know that he becomes the new owner. Staying anonymous while signing is made possible by group signing. M.Dupond therefore calls on the services of a certification authority issuing a group signature. He joins a group that checks his identity before he does provide the means to create your keys and register them as a certified member. Such a process is shown diagrammatically in Figure 11.
  • Precondition For the client, have a certificate, have chosen an article, authorize the loading of signed applets; for the auction server, having obtained the means to verify anonymous authentication (second step of the process);
  • M.Dupond presents its request using a signed token.
  • This first token noted W1000 for M.Dupond and X1000 for another customer (see Figure 13), serves as initialization and proof for the rest of the sale.
  • This first token is generated and signed by the customer with his private key using an applet transmitted by the auction site.
  • the token is associated with the parameters of the sale, item identifier, current price and step value.
  • the signature is anonymous thanks to the group signature.
  • Unfolding phase Auction; it is part of the third step of the process;
  • the token ensures the authenticity, integrity and confidentiality of the auction order; - Precondition: Being registered for sale, the token has a parentage;
  • M.Martin participates in the auction of the photography he has chosen with a starting price of 600 euros and a step of 10 euros. He is the first bidder and he agrees to bid at 610 euros by transmitting a token (W999). During the auction, a second customer increases the price to 620 euros. M.Martin is ready to add more and click on the button to bid at 630 euros. It then transmits the token of index 997, noted W997. Indeed, as described above, each token corresponds to a value calculated according to the starting price and the step of the auction.
  • the index 999 represents the value 610 euros, 998-620, 997-630, 996-640, ...;
  • Unfolding phase Auction; it is part of the third step of the process;
  • Security level The token ensures client authenticity and data integrity; - Precondition: Having an initialization token for a particular customer's bids on an item;
  • Security level Identify the winner and lift the anonymity of the winner in the event of a group signature
  • Registration for participation in a sale Registration for a sale is linked to a session. It is therefore necessary to reset the registration in the event of disconnection or change of session;
  • FIG. 20 This architecture is shown schematically in Figure 20.
  • a Client browser an ACA Server and an Auction Server (the latter each being associated with a specific database) capable of implementing the above steps.
  • Oracle is a relational DBMS (database management system) published by the company of the same name.
  • Oracle has a language for defining and manipulating data: SQL (Structured Query Language), which has become the standard language in the field of relational databases.
  • SQL * PLUS is the Oracle user interface which allows you to interactively use the SQL language on an Oracle instance.
  • the programming language and technologies used for implementation are Java.
  • the application is managed by the IBM WebSphere 3.5 product. WebSphere Application Server allows you to perform transactions and Web interactions.
  • Java web applications focused on supporting and running napkins, JavaBeans, and Java Server Pages (JSP) files. It is an interface with the Web server to manage client requests for resources on the server side and to route them to the application server for processing.
  • the tool used in WebSphere is the servlet engine. It runs inside the application server and handles requests for napkins, Java Server Pages (JSP) files, and the web applications that contain them.
  • the client workstation was tested on a Windows system with the Java Plug-in.
  • the Plug-in (provided by Sun) is used to update the browser JVM version (IE or Netscape).
  • the Java-plugin replaces the default Java Runtime of the browser with the JRE from Sun.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Strategic Management (AREA)
  • Computing Systems (AREA)
  • General Business, Economics & Management (AREA)
  • Software Systems (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Computer And Data Communications (AREA)

Abstract

La présente invention concerne un procédé d'accès à un service consistant à ij identifier et enregistrer un Client (C), ii authentifier le Client auprès d'une Autorité de Certification Anonyme, iii) authentifier le Client par la production d'une signature anonyme et ouvrir et maintenir une session d'authentification anonyme auprès d'un Serveur (Se), et iv permettre sélectivement un contact entre le Serveur (Se) et l'Autorité de Certification Anonyme (ACA) pour lever l'anonymat du Client (C) sur la base de la signature fournie à l'étape iii). L'invention concerne également un système apte à permettre l'ouverture et le maintien d'une session d'authentification garantissant la non répudiation.

Description

PROCEDE ET SYSTEME AVEC AUTHENTIFICATION, ANONYMAT REVOCABLE ET NON REPUDIATION
DOMAINE TECHNIQUE
L'invention concerne le domaine de la sécurité des accès à des services, notamment à des ressources informatiques.
L'invention a pour objectif général d'offrir un service d'authentification forte et anonyme d'utilisateurs et un mécanisme rapide et économique de maintien de session d'authentification. L'invention permet, malgré l'anonymat, de responsabiliser les utilisateurs en offrant aux ressources la possibilité de lever l'anonymat de l'utilisateur le cas échéant (en cas de litige par exemple).
APPLICATIONS
L'invention peut trouver de nombreuses applications. Celles qui seront indiquées par la suite ne doivent pas être considérées comme limitatives.
Les applications majeures de cette invention sont les enchères électroniques ou les jeux en réseau/communauté. En fait, l'invention est adaptée en particulier à toute application dont le but est de proposer une place publique où plusieurs utilisateurs peuvent se réunir et échanger tout en gardant leur anonymat.
L'invention est particulièrement pertinente pour les enchères électroniques dont le but est de reproduire le principe de fonctionnement des enchères réelles. Les enchères réelles permettent à des personnes, réunies dans une même salle, de faire des offres de manière anonyme. Bien que leur identité réelle ne soit jamais dévoilée, les participants ne peuvent pas se rétracter. La présente invention offre les mêmes propriétés d'authentification anonyme et de non-répudiation.
Ces mêmes fonctionnalités peuvent également être exploitées pour des applications de jeux multi-acteurs, tels que les jeux de casino, où plusieurs personnes se réunissent autour d'une même table de jeux sans se connaître les uns les autres. Lorsqu'un joueur mise sur un numéro, il ne peut pas nier avoir misé sur ce numéro. La présente invention offre ces propriétés : elle" garantit l'anonymat des joueurs (l'identité des joueurs n'est pas révélée) tout en les responsabilisant (l'identité des joueurs pourra être révélée si besoin).
ETAT ACTUEL DES CONNAISSANCES PUBLIEES SUR LE SUJET (ART ANTERIEUR LE PLUS PROCHE) - INCONVENIENTS DE LA TECHNIQUE ANTERIEURE
Le but général de l'invention est de proposer des moyens permettant 1) de garantir l'anonymat des clients, 2) de maintenir efficacement une session d'authentification et 3) de responsabiliser les clients. Aujourd'hui, un certain nombre de techniques permettent de répondre en partie à ces exigences, mais aucune n'offre de solution complète à la problématique globale.
Certaines techniques permettent à un serveur d'authentifier un client. Ces techniques sont généralement couplées à un mécanisme permettant de maintenir une session d'authentification entre l'utilisateur et le serveur.
Les techniques majeures offrant des services d'authentification et de maintien de session sont les suivantes : 1) les mots de passe jetables, 2) les techniques SSL et TLS et 3) la technique Kerberos. • Les mots de passe jetables : le principe des mots de passe à usage unique - encore appelés mots de passe jetables ou OTP (One- Time Password) - consiste à utiliser des mots de passe qui ne peuvent être utilisés qu'une seule fois. Même si le mot de passe est dérobé, il n'est pas réutilisable. Dans la pratique, ce dispositif prend généralement la forme d'une cartulette (ex. ActivCard, SecurlD) qui calcule les mots de passe que l'utilisateur doit saisir pour s'authentifier. Ce mot de passe est ensuite utilisé pour calculer une clé de session (une clé secrète) destinée à garantir la confidentialité et l'intégrité des échanges.
• SSL et TLS : ce sont des techniques qui reposent sur des certificats et des algorithmes de cryptographie à clés publiques (ou asymétriques) pour l'authentification et des algorithmes de cryptographie à clés secrètes (ou symétriques) pour le maintien de session. Un certificat constitue une carte d'identité numérique. Il prend la forme d'un fichier contenant une clé publique et des informations sur son propriétaire. Ces informations sont certifiées (i.e. signées) par une autorité de confiance appelée autorité de certification. Typiquement, pour authentifier un utilisateur, un serveur lui envoie un challenge (une valeur numérique aléatoire) que l'utilisateur signe avec sa clé privée. La clé publique permet au serveur de vérifier que l'utilisateur possède bien la clé privée, le certificat de connaître l'identité de l'utilisateur. En outre, cette phase d'authentification permet au client et au serveur de s'échanger une clé de session (une clé secrète) qui leur permettra de garantir la confidentialité et l'intégrité de leurs échanges.
• Kerberos : il s'agit d'un mécanisme de SSO (Single Sign- On) permettant à un utilisateur d'accéder à plusieurs ressources sans avoir à s'authentifier plusieurs fois. Il repose sur des algorithmes de cryptographie à clé secrète. Typiquement, pour accéder à un serveur, l'utilisateur s'authentifie auprès d'un distributeur de clés ou KDC (Key Distribution Center) qui lui retourne un jeton d'authentification pour ce serveur cible. Ce jeton est envoyé de manière transparente au serveur cible et lui permet d'identifier/authentifier l'utilisateur et de récupérer une clé de session (une clé secrète) utilisée par le serveur et le client pour garantir la confidentialité et l'intégrité de leurs échanges.
Les inconvénients majeurs de ces techniques connues sont les suivants :
• L'anonymat des utilisateurs n'est pas préservé : Les mécanismes d'authentification proposés par ces techniques sont destinés à vérifier l'identité réelle du client. Cette identité est dévoilée par le login dans le cas des mots de passe jetables, par le certificat dans le cas de TLS et SSL ou par le jeton d'authentification dans le cas de Kerberos.
• La non-répudiation n'est pas garantie : Ces techniques s'appuient sur des algorithmes de cryptographie à clé secrète pour maintenir la session d'authentification et garantir la confidentialité et l'intégrité des échanges. Ce type d'algorithme cryptographique ne permet pas de garantir la non-répudiation ; Le client peut toujours nier avoir envoyé un message.
• Le maintien de la session est coûteux : le maintien de la session est réalisé en chiffrant ou en authentifiant les messages que le client et le serveur s'échangent. Le client doit, en permanence, disposer de moyens de calculs pour maintenir la session.
D'autres techniques offrent des mécanismes d'authentification permettant de préserver l'anonymat des utilisateurs.
L'utilisation d'un pseudonyme est l'approche la plus couramment utilisée par les serveurs actuellement déployés sur Internet (ex. les sites d'enchères électroniques, les sites de jeux). Cette technique repose sur un mécanisme d'authentification basé sur l'utilisation d'un login (i.e. le pseudonyme) et d'un mot de passe. Les utilisateurs s'enregistrent généralement auprès du serveur en renseignant un certain nombre d'informations personnelles et en choisissant un pseudonyme et un mot de passe qu'ils devront ensuite présenter pour s'authentifier. Cette approche pose un certain nombre de problèmes :
• Problème d'ergonomie : chaque utilisateur doit s'enregistrer auprès de chacun des serveurs en entrant plusieurs fois les mêmes informations.
• Problème d'anonymat : Les informations personnelles des utilisateurs sont stockées sur chaque serveur. L'anonymat d'un utilisateur est garanti vis-à-vis des autres utilisateurs mais pas vis-à-vis du serveur. L'utilisateur doit donc faire totalement confiance à chacun des fournisseurs de services.
• Problème d'identification et de responsabilisation : les informations renseignées par l'utilisateur ne sont pas ou peu vérifiées. L'utilisateur est authentifié mais faiblement. Il peut donc entrer des informations erronées, se faire passer pour quelqu'un d'autre ou s'enregistrer plusieurs fois en utilisant différents pseudonymes. D'une manière générale, cette approche ne permet pas de responsabiliser l'utilisateur puisque le serveur ne peut rien prouver. • Problème de traçabilité : le serveur peut suivre les activités de ses clients et peut ainsi en déduire un profil, information souvent plus intéressante que l'identité réelle. L'anonymat n'est donc pas complètement garanti. Les techniques de signature de groupe voir documents ([1], [2],
[3] et [4] et utilisées notamment pour les enchères électroniques dans l'article [5]) offrent également un mécanisme d'authentification anonyme. Le principe général consiste, pour un client, à s'inscrire auprès d'une autorité de confiance, le gestionnaire du groupe. Les clients enregistrés auprès de cette autorité appartiennent à un même groupe et disposent des moyens nécessaires pour signer au nom du groupe. Tout serveur dispose des moyens pour vérifier une signature. La vérification d'une signature consiste, en fait, à vérifier qu'elle a bien été produite par un membre du groupe ; Elle ne dévoile rien sur le membre qui l'a produite et ne permet donc pas au serveur de connaître son identité. L'anonymat des clients est donc garanti. Un serveur peut, néanmoins, interroger le gestionnaire de groupe pour lever l'anonymat du signataire.
Cette technique répond donc à la problématique d'authentification anonyme. En revanche, elle n'intègre aucun mécanisme permettant de maintenir une session d'authentification entre un client et un serveur. Le serveur ne peut donc pas se "souvenir" de l'identité du client. Pour maintenir l'authentification, le client doit signer chacun des messages qu'il transmet au serveur et doit donc disposer en permanence des moyens de calcul nécessaires. De plus, les calculs mis en œuvre pour réaliser de telles signatures sont assez conséquent et ne permettent pas une authentification rapide.
BUT DE L'INVENTION
Un but de l'invention est de fournir une solution complète à la problématique d'authentification anonyme et de maintien de session. BASE DE L'INVENTION
Le but précité est atteint dans le cadre de la présente invention grâce à un procédé qui comprend les étapes consistant à : 0 identifier et enregistrer un Client et lui fournir des moyens lui permettant de s'authentifier auprès d'une Autorité de Certification Anonyme,
H} authentifier le Client auprès de I' Autorité de Certification Anonyme sur la base des moyens fournis en i) et fournir des moyens lui permettant de s'authentifier de manière anonyme auprès d'un Serveur , iii) authentifier le Client par la production d'une signature anonyme et ouvrir et maintenir une session d'authentification anonyme auprès d'un Serveur, et iy permettre sélectivement un contact entre le Serveur et l'Autorité de Certification Anonyme pour lever l'anonymat du Client sur la base de la signature fournie à l'étape iii).
L'étape i) consiste avantageusement pour un Client utilisateur à récupérer, auprès de l'Autorité de Certification Anonyme formant un tiers de confiance, les informations (une clé publique et un certificat) lui permettant de calculer des signatures anonymes. Tout serveur ou ressource peut vérifier ces signatures sans que l'identité réelle de l'utilisateur ne lui soit révélée. Une signature valide garantie à la ressource ou serveur qu'il pourra, le cas échéant, recouvrer l'identité réelle de l'utilisateur en interrogeant le tiers de confiance.
La présente invention propose ainsi une solution complète et globale pour :
• Garantir l'anonymat des clients : l'invention repose sur des mécanismes d'authentification forte permettant de préserver l'anonymat des clients ;
• Maintenir efficacement une session d'authentification : le mécanisme de maintien de session d'authentification que propose l'invention ne nécessite aucun calcul côté client. Toutes les informations nécessaires sont calculées au cours de la phase d'authentification ; • Responsabiliser les clients : L'invention permet de garantir la non-répudiation. D'une part, parce qu'à tout moment, le serveur peut lever l'anonymat d'un client en interrogeant un tiers de confiance. D'autre part, parce que le serveur peut prouver chacune des actions d'un client.
La présente invention concerne également un système apte à permettre l'ouverture et le maintien d'une session d'authentification garantissant la non répudiation, caractérisé par le fait qu'il comprend des moyens adaptés pour la mise en œuvre de trois phases : . une première phase dans laquelle un Client calcule un ensemble de données, formé d'une suite de jetons, l'un de ceux-ci permettant d'ouvrir une session, tandis que les autres permettent de la maintenir, . une deuxième phase dans laquelle le Client s'engage fortement sur la suite de jetons après d'un Serveur, et
. une troisième phase de maintien de la session à l'aide de la suite de jetons.
On notera que dans le contexte de ce système d'ouverture et de maintien de session, le Client dispose de moyens lui permettant de produire une signature digitale qui n'est pas obligatoirement anonyme, bien que préférentiellement elle le soit bien entendu.
Les documents [12], [13] et [14] décrivent diverses modalités d'enchères électroniques. Aucun de ces documents n'enseigne ni ne suggère une ouverture et un maintien de session, permettant des interventions multiples successives du client, au sein de la même session résultant d'une seule et unique authentification initiale. En effet, selon les modalités définies dans chacun de ces documents, les enchérisseurs n'envoient qu'une seule valeur ou donnée. D'autres caractéristiques, buts et avantages de la présente invention apparaîtront à la lecture de la description détaillée qui va suivre, et en regard des dessins annexés, donnés à titre d'exemples non limitatifs et SUF lesquels : •=*
- la figure 1 représente l'architecture générale des moyens relationnels mise en jeu dans le cadre de la présente invention,
- la figure 2 représente un organigramme schématique du procédé conforme à la présente invention,
- la figure 3 schématise le processus d'identification forte, - la figure 4 schématise le processus de certificat anonyme,
- la figure 5 schématise le processus de signature aveugle à anonymat révocable,
- la figure 6 schématise le processus de signature de groupe, - la figure 7 schématise l'application de la présente invention à un processus d'enchères électroniques,
- la figure 8 schématise une étape préparatoire de mise en vente et consultation dans le contexte d'enchères électroniques,
- la figure 9 schématise un exemple de fiche article mise à disposition d'un visiteur, Client potentiel, dans le cadre d'une vente aux enchères,
- la figure 10 schématise une étape d'obtention de certificat anonyme,
- la figure 11 schématise les étapes d'inscription de groupe, génération de clés et envoi de certificat dans ce contexte,
- la figure 12 schématise une étape de demande de participation avec certificat et autorisation,
- la figure 13 schématise les étapes d'initialisation puis de génération de jetons par deux Clients respectifs dans le cadre d'enchères,
- la figure 14 schématise une étape de participation à une vente aux enchères, - la figure 15 schématise les étapes de surenchères par transmission de jeton dont l'indice (ou "rang") représente la valeur choisie pour la surenchère,
- la figure 16 schématise une étape de traitement des ordres d'enchères, - la figure 17 schématise le traitement d'un jeton reçu d'un Client et la comparaison de la valeur représentée par son indice avec les données antérieurement reçues,
- la figure 18 schématise une étape de conclusion de vente aux enchères, - la figure 19 schématise des étapes d'information de Client gagnant d'enchères, de Clients perdant, de vendeur et de fin de transaction, et
- la figure 20 schématise une architecture Client-Serveur permettant de mettre en oeuvre le procédé à la présente invention. Comme indiqué précédemment et illustré sur la figure 1 annexé, l'invention met en oeuvre trois entités dans le protocole : des Clients C, au moins une Autorité de Certification Anonyme ACA et au moins un Serveur (ou "Ressource") Se.
Comme également indiqué précédemment, l'invention propose, d'une part, un mécanisme d'authentification anonyme basé sur l'utilisation de certificat anonyme. Elle propose, d'autre part, un mécanisme de maintien de session économique et efficace garantissant la non-répudiation. Enfin, elle propose une solution globale combinant les mécanismes d'authentification anonyme (ex. signature de groupe, certificat anonyme) et le mécanisme de maintien de session pour répondre aux problématiques suivantes :
• L'anonymat des utilisateurs : l'invention repose sur des mécanismes d'authentification forte permettant de préserver l'anonymat des utilisateurs, non seulement vis-à-vis des autres utilisateurs, mais aussi vis-à-vis des serveurs ;
• L'efficacité et portabilité : le mécanisme de maintien de session d'authentification que propose l'invention ne nécessite aucun calcul côté utilisateur. Toutes les informations nécessaires sont calculées préalablement au cours de la phase d'authentification ;
• La non-répudiation : L'invention permet de garantir la non- répudiation. D'une part parce qu'à tout moment, le serveur peut lever l'anonymat d'un utilisateur en interrogeant le tiers de confiance ACA. D'autre part parce que le serveur peut prouver chacune des actions d'un utilisateur.
• L'ergonomie : l'utilisateur s'enregistre une seule et unique fois auprès d'un tiers de confiance ACA. _ -≈---.
L'Autorité de Certification Anonyme (ACA) délivre des certificats anonymes et est adaptée et habilitée pour lever l'anonymat le cas échéant. Le Serveur fournit des services à des personnes C désirant rester anonyme, cet anonymat pouvant être levé quand cela est nécessaire. Un Client va obtenir un certificat anonyme dans le but de s'authentifier anonymement puis de maintenir une session auprès d'un Serveur.
Le procédé conforme à l'invention dans une mise en oeuvre préférentielle comprend essentiellement 4 étapes. • Etape 1 : l'identification. Le Client C s'enregistre auprès d'une autorité de confiance (cette autorité peut être soit l'Autorité de Certification Anonyme elle-même, soit une autorité de certification). Cette étape consiste pour l'utilisateur à fournir des informations personnelles (nom, prénom, adresse, etc .). Plusieurs alternatives sont possibles pour cela. Par exemple, le client peut s'enregistrer soit en ligne en remplissant un formulaire électronique, soit en se déplaçant physiquement dans un endroit bien précis. L'autorité de confiance vérifie l'identité du client et toutes ou une partie de ses informations personnelles, stockent ces informations pour une utilisation future et fournit au Client les moyens (par exemple un login/mot de passe ou un certificat) qui lui permettront de s'authentifier auprès de l'ACA. Il est à noter que dans tout le reste du protocole, le Client ne fournira plus à aucun moment ses données personnelles.
• Etape 2 : l'authentification auprès de l'ACA. Cette étape met en jeu le Client et l'ACA. Le Client s'authentifie de manière forte auprès de l'ACA (en utilisant les moyens qu'il a obtenus à l'étape 1). L'ACA lui délivre en retour les moyens de produire une signature anonyme. Elle se garde les moyens de pouvoir relier à tout moment le Client (i.e. la personne physique qu'elle connaît à l'aide de l'authentification forte) à n'importe quelle signature émanant de celui-ci.
• Etape 3 : l'authentification anonyme auprès du Serveur. Cette étape met en jeu un Serveur et un Client. Ce dernier désire maintenir une session pour accéder aux services qu'offre le Serveur et doit pour cela faire savoir à ce dernier qu'il s'est authentifié de manière forte auprès de l'ACA. Pour autant, le Client veut rester anonyme vis-à-vis du Serveur et d'autres clients potentiels. Le but de cette étape est d'ouvrir une session auprès due Serveur en faisant un certain nombre de calculs pour ensuite pouvoir maintenir cette session de manière très rapide. Cette étape va ainsi se diviser en trois phases. La première phase va permettre au Client de calculer un ensemble de données (une suite de jetons), l'un de ces jetons permettant d'ouvrir la session alors que les autres permettront de la maintenir. La deuxième phase permettra au Client de s'engager fortement sur cette suite de jetons auprès du Serveur. La troisième phase consistera à maintenir la session à l'aide de cette suite.
Remarque 1 : Dans certains cas (par exemple lorsque le service d'anonymat est facturé aux serveurs), l'ACA peut exiger une authentification des Serveurs qui veulent offrir le service d'anonymat à leurs utilisateurs. Pour cela, l'ACA doit pouvoir exiger une authentification des serveurs avant de remettre un certificat anonyme à l'utilisateur et/ou avant de lever l'anonymat. Les serveurs doivent donc préalablement se soumettre à une phase d'enregistrement auprès de l'ACA. Pour cela, chaque serveur fait une demande d'affiliation à l'ACA qui étudie la proposition (suivant des critères qu'elle a établis) et décide d'accepter ou non la proposition.
Remarque 2 : Les deux premières phases nécessitent un dialogue entre l'utilisateur et l'ACA d'une part (première phase), et entre l'utilisateur et le serveur d'autre part (seconde phase). Elles seront donc typiquement réalisées en utilisant un navigateur web ou une application hébergée sur le poste du client. Toutefois, puisque la suite de jetons est pré-calculée au cours de la phase d'authentification, elle peut être embarquée dans un terminal portable (téléphone mobile, PDA, ...). L'utilisateur peut donc s'authentifier auprès du serveur en utilisant un navigateur ou une application et maintenir ensuite la session d'authentification en utilisant un autre type de terminal.
Tous les jetons sont à usage≈- unique et sont fortement dépendants les uns des autres. Ils ne peuvent être calculés que par le Client et sont non-falsifiables. N'importe qui, et en l'occurrence le Serveur, peut vérifier la dépendance (et donc la provenance) de ces jetons. Dans un premier temps donc, le Client, au cours de l'ouverture de la session, calcule la suite de jetons. L'algorithme de génération des jetons est basé sur l'utilisation de deux primitives cryptographiques : une fonction de hachage et un nombre aléatoire. Une fonction de hachage H() possède les propriétés suivantes :
- H(M) opère sur un message M de longueur arbitraire
- Le résultat h = H(M) possède une longueur I fixe
- Etant donné M, il est facile de calculer h
- Etant donné M, il est difficile de trouver un autre message M0 tel que H(M) = H(M0)
Parmi les fonctions de hachage, nous pouvons citer MD5 ("Message Digest 5") ou SHA ("Secure Hash Algorithm"). SHA produit une sortie de 160 bits appelée message abrégé.
Afin d'initialiser l'ensemble des jetons, il est nécessaire de générer un nombre aléatoire à partir duquel la fonction de hachage va calculer les jetons. Ce nombre aléatoire doit être cryptographiquement sûr, c'est-à-dire qu'il faut que la probabilité de réussite de la recherche exhaustive soit quasi nulle.
La fonction de hachage appliquée à ce nombre aléatoire W0 permet d'obtenir un résultat Wi (c'est-à-dire un premier jeton) auquel on applique à nouveau la fonction de hachage pour obtenir un deuxième jeton W2 et ainsi de suite pour obtenir n jetons : H(W0) = \Nlt ..., H(Wn-ι) = Wn
La suite de jetons est donc (Wn,Wn-ι,Wn-2,...,Wι,Wo). Du fait des propriétés des fonctions de hachage, il est facile, à partir de W0/ de calculer n'importe lequel des Wj (pour i allant de 1 à n) alors qu'il est impossible en pratique de retrouver W0 à partir des Wj (pour i allant de 1 à n). - •«-
Dans un second temps, le Client utilise ses moyens d'authentification forte anonyme obtenus à l'étape 2 pour produire une signature anonyme du jeton d'initialisation Wn, la signature permettant au serveur d'authentifier ce Client (il peut vérifier la validité de la signature et donc être convaincu des droits du client qu'il a en face de lui). Le Client vient ainsi d'ouvrir une session anonyme auprès du Serveur. Il va pouvoir maintenir cette session à l'aide de la suite de jetons. Le jeton Wn est stocké par le Serveur et sera utilisé pour vérifier la validité des autres jetons (et donc de la session). Remarque : Au cours de la phase d'authentification anonyme, un certain nombre d'informations peuvent être associées au jeton d'initialisation (par exemple, la valeur numéraire d'un jeton). Ces informations constituent les informations de session et permettent de décrire la sémantique associée à chaque jeton. Un jeton permettra donc au serveur de retrouver l'identité de l'émetteur mais également les informations de session.
Au cours de la session, le Serveur veut être sûr de pouvoir retrouver l'identité physique du client qu'il a en face de lui, selon le principe défini à la quatrième étape. De plus, il faut que cette authentification se fasse rapidement. Pour cela, le Client transmet simplement, à chaque nouvelle authentification, un jeton de la liste calculée précédemment : Wn-ι, puis Wn-2,Wn-3, ... Pour poursuivre la session, le Client transmet ainsi les jetons dans l'ordre de n - 1 à 0.
D'une manière générale, si le résultat de h(Wn-ι) est bien égal à Wn alors l'authentification est acceptée. Le Serveur est capable de vérifier ce lien : le jeton Wj reçu est comparé avec les jetons de l'ensemble des clients présents dans la base. Ainsi, pour trouver dans la base le Wk relié au Wj reçu, il utilise la formule : h'(W|) = Wk (en utilisant le fait que h2(Wn-2)=h(h(Wn-2))=h(Wn-1)=Wn). Si le Serveur parvient à trouver dans sa base ce jeton Wk, alors il accepte la poursuite de la session et le jeton Wi remplace le jeton Wk pour la vérification suivante. Dans le cas contraire, le jeton n'appartient pas à un client et l'authentification est refusée. - -≈-
Lors des diverses authentifications se déroulant au cours de la session, le Serveur sait ainsi toujours relier un jeton (et donc la session) à la signature anonyme effectuée au moment de l'ouverture de cette session. • Etape 4 : Elle met en jeu un Serveur et l'Autorité de confiance. Le premier a en sa possession une signature qu'il sait émanant d'un Client s'étant identifié de manière forte auprès de l'ACA. S'il le souhaite, il peut donc envoyer cette signature à l'ACA qui a les moyens de découvrir l'identité physique du signataire (cf. première étape) et de fournir cette information au Serveur. Ce dernier peut ainsi obtenir l'identité physique du Client ayant produit la signature et l'ensemble des jetons qu'il a reçu au cours de sa session.
Une variante consiste à faire en sorte que le Serveur ne connaisse à aucun moment l'identité du Client. Dans ce cas, une fois la levée d'anonymat effectuée par l'ACA, ce dernier contacte personnellement le Client impliqué et termine ainsi la session de la manière adéquate.
Dans certains cas, le droit de production de signature anonyme a une durée de vie limitée (par exemple liée à une seule session). Dans ce cas, le Client devra s'authentifier de manière forte auprès de l'ACA à chaque session (i.e. pour chaque suite de jeton).
Le nombre de sessions liées à un engagement est limité dans le temps. En effet, la suite de jetons est finie. Une fois le dernier jeton envoyé, le Client doit produire une nouvelle suite de jetons auprès du Serveur et doit signer anonymement le jeton d'initialisation.
D'autre part, l'étape 3 peut être utilisée seule pour ouvrir et maintenir efficacement une session d'authentification. Ainsi, un Client va pouvoir s'authentifier de manière forte auprès du serveur (mais sans anonymat cette fois-ci) et maintenir une session, de manière très rapide, à l'aide de la suite de jetons qu'il aura préalablement calculés. Cette approche permet, en outre, de garantir la non-répudiation.
DESCRIPTION DETAILLEE D'UN MODE DE REALISATION
Spécification du mécanisme de jetons Jeton d'initialisation
Le premier jeton envoyé par le Client au Serveur est appelé jeton d'initialisation et permet d'ouvrir la session. Il est lié, à la fois, à l'authentification du Client à partir d'une signature et aux informations de session. Ainsi, le jeton d'initialisation fixe par association, dans un message envoyé par le Client au Serveur, la preuve d'authentification et les paramètres d'initialisation de la session.
Dans le cas des enchères, dont l'application est décrite par la suite, le mécanisme de jetons est utilisé dans la phase de participation à une vente. Un Client demande une participation à la vente aux enchères en transmettant un message composé du jeton d'initialisation associé aux paramètres de la vente, par exemple, l'identifiant de l'article, son prix actuel, et la valeur du pas. C'est ce message qui est signé. Le Client transmet également, dans cette demande de participation, les moyens pour le serveur de vérifier la signature (message, clé publique, certificat...) et donc d'authentifier le Client, en fonction du mécanisme de signature utilisé. Des spécifications du mécanisme de signature seront décrites ci-dessous. Si l'authentification du Client par le Serveur est valide, le jeton d'initialisation et les données transmises par le Client, dans cette demande de participation, sont enregistrés par le Serveur d'Enchères. Jetons de maintien de session Dans le cas des enchères, si le Serveur autorise le Client à participer à la vente après avoir reçu le jeton d'initialisation, le Client peut alors surenchérir en envoyant au Serveur les jetons successifs et seulement les jetons. En effet, chaque ordre d'enchère du Client se traduit par l'envoi d'un jeton sans autre information ni signature. A partir des informations enregistrées avec le jeton d'initialisation, le Serveur est capable d'authentifier l'ordre en attribuant le jeton à son Client propriétaire et de calculer sa valeur. Ainsi, chaque jeton reçu par le Serveur est comparé avec l'ensemble des jetons enregistrés. Par dépendance entre jetons, l mouveau jeton reçu par le Serveur ne peut correspondre qu'à un seul jeton présent dans la base. Le Serveur retrouve les informations sur le Client et sur l'article lié au jeton reçu en le mettant en correspondance avec un jeton stocké et un seul. Selon ce procédé, le mécanisme de jetons peut s'appliquer aux enchères en établissant des règles de calcul. Côté client, le calcul de l'indice i du jeton Wi pour surenchérir (prixsup) est basé sur le prix actuel de l'article (prixmax) et du pas de l'article (pas). Les formules peuvent être : prixsup = prixmax + pas j = (prixsup - prixdedepart)/pas i = nombretotaldejetons - j
Côté serveur, le jeton Wi reçu est comparé avec les jetons présents dans la base. Les formules permettant de retrouver le jeton et de calculer sa valeur peuvent être : - Pour trouver dans la base Wk, la formule est : h'(Wι) = Wk
- Pour calculer la valeur de Wj, la formule est : Wj = prixdeWk + (I *pas)
Spécification du mécanisme de signature du jeton d'initialisation.
La signature du jeton d'initialisation permet l'ouverture d'une session et peut être réalisée, selon les cas, avec ou sans anonymat. Le Client possède une clé privée SK, une clé publique PK et un certificat (anonyme ou non). Il utilise sa clé privée SK et un algorithme cryptographique (par exemple RSA, DSA ou signature de groupe) pour signer un message composé du jeton d'initialisation Wn et des informations de session session_data. Il obtient ainsi une signature S- Sigsk (Wn, session_data) qu'il envoie au Serveur avec le message, sa clé publique PK et le certificat C qui relie cette clé publique à son identité propre.
La figure 3 schématise les détails du protocole de signature du jeton d'initialisation.
Spécification des mécanismes de signature anonyme.
Certificat anonyme
Lors de la seconde étape, le Client C crée une paire de clés publique PK - privée SK (par exemple des clés RSA). Il garde secret la clé privée et envoie à l'ACA la clé publique PK afin d'obtenir, lors d'une session authentifiée fortement, un certificat AC=SigACA (PK, Pseudo) de cette clé liée à un pseudonyme choisi par l'ACA et/ou le Client. Ce pseudonyme peut éventuellement être le chiffrement de la véritable identité du Client accompagnée d'un aléa. La levée de l'anonymat se fait ainsi facilement par l'ACA qui déchiffre ce pseudonyme pour obtenir l'identité du Client. L'ACA garde en mémoire le lien entre le Client et son pseudonyme pour, par la suite, pouvoir lever l'anonymat. Remarque : D'une manière générale, un certificat anonyme permet de lier un pseudonyme à une clé publique. Mais il peut également, en fonction du contexte, contenir d'autres informations permettant de limiter la portée du certificat (ex. l'identifiant du serveur, l'identifiant d'une session, une date de validité, l'adresse IP du client, le contexte d'authentification ...).
L'étape de signature du jeton d'initialisation consiste pour le Client à utiliser sa clé privée PK (il s'agit donc d'une signature RSA). Le message est constitué du jeton d'initialisation W1000, de la signature S, de la clé publique PK et du certificat lié au pseudonyme AC+Pseudo. Le Serveur ouvre donc une session avec un client qu'il ne connaît que sous un pseudonyme. Il vérifie ainsi que le Client s'est authentifié fortement auprès de l'ACA à l'aide du certificat AC et que la clé publique PK certifiée (et appartenant au pseudonyme) permet bien de vérifier la signature du jeton d'initialisation. La levée de l'anonymat est mise en œuvre lorsque le Serveur fournit à l'ACA le certificat (ou le pseudonyme). L'ACA peut savoir à quel Client correspond ce pseudonyme et donc qui a produit la signature.
La figure 4 schématise les détails des protocoles de certificat anonyme. II est à noter que pour obtenir un anonymat intéressant, il convient de changer de certificat (et donc de paire de clé de signature) à chaque session. Il faut donc que le Client se connecte à l'ACA à chaque session. ~ CT~~
Remarque : si le Client désire se connecter à plusieurs serveurs bénéficiant des services de l'ACA, au moins deux possibilités s'offrent à lui. Soit l'ACA fournit un seul certificat (universel) pour l'ensemble des serveurs, auquel cas il est possible de tracer le pseudonyme de ce Client sur l'ensemble des sites (on ne sait pas qui il est mais on sait ce qu'il fait sur chacun des serveurs). Soit l'ACA fournit un certificat par serveur , auquel cas on perd l'universalité du certificat mais il est alors impossible de tracer un même client sur plusieurs serveurs.
Chaque serveur fournit au Client un identifiant qui est retransmit à l'ACA. Ce dernier sait alors qu'il a fournit à tel Client un certificat pour tel Serveur et donc n'en fournira pas deux.
Remarque : de même, si le Client possède deux machines à partir desquelles il désire accéder au Serveur (par exemple une machine à son lieu de travail et une machine chez lui), il doit pouvoir obtenir deux certificats différents de la part de l'ACA.
Certificat aveugle à anonymat révocable
Une partie du processus conforme à la présente invention peut s'apparenter à un certificat aveugle à anonymat révocable.
Le concept de schéma de signature aveugle a été introduit par Chaum à Crypto'83. Un schéma de signature aveugle est un protocole mettant en jeu deux entités : un signataire et un utilisateur. Il permet à l'utilisateur d'obtenir la signature d'un message donné faite par le signataire, sans que ce dernier n'apprenne quoi que ce soit à propos du message. Le modèle de la signature aveugle à anonymat révocable est constitué de plusieurs utilisateurs, d'un signataire, d'une autorité reconnue, par exemple un juge, et de deux protocoles :
- Un protocole de signature entre le signataire et l'utilisateur.
- Un protocole de recouvrement entre le signataire et le juge. A l'aide du protocole de signature, l'envoyeur obtient une signature valide du message de son choix de telle sorte que le signataire ne peut pas relier le protocole et la paire message/signature. Il existe deux types- de signature aveugle à anonymat révocable, suivant l'information que le juge reçoit du signataire pendant le second protocole :
- Révocation de type 1 : à l'aide de la partie du protocole venant du signataire, le juge donne l'information qui permet au signataire (ou à n'importe qui) de reconnaître le message (i.e. le juge peut retrouver le message).
- Révocation de type 2 : à l'aide du message et de la signature, le juge permet au signataire de retrouver efficacement l'utilisateur ou la partie du protocole correspondant à la signature.
On se reportera aux documents [6], [7], [8], [9], [10] et [11] pour disposer d'exemples de schéma de signature aveugle à anonymat révocable (en anglais "fair blind signature").
Dans le cas de l'invention (révocation de type 2), l'ACA joue le rôle du signataire et le Serveur joue celui de juge. Le Client est l'utilisateur. Lors de la première étape, le Client crée une paire de clés publique PK - privée SK (par exemple de type RSA). Il garde secret la clé privée de signature et envoie à l'ACA la clé publique PK afin d'obtenir, lors d'une session authentifiée fortement, une signature aveugle BC à anonymat révocable (protocole d'obtention de certificat) de cette clé (la signature aveugle correspond à son certificat anonyme). L'ACA garde en mémoire les moyens de lever l'anonymat de cette signature. Sur la figure 5, cette signature aveugle est intitulée BC=BSigACA (PK). L'étape de signature du jeton d'initialisation (protocole de signature de jeton) consiste pour le Client à utiliser sa clé privée PK pour signer (il s'agit donc d'une signature RSA). Le message est constitué du jeton d'initialisation W1000, de la signature S, de la clé publique PK et du certificat anonyme BC. Le Serveur vérifie ainsi que le Client s'est authentifié fortement auprès de l'ACA à l'aide du certificat anonyme (il vérifie que la signature BC émane bien de l'ACA) et que la clé publique PK certifiée permet bien de vérifier la signature S du jeton d'initialisatrσn.-
La levée de l'anonymat est mise en œuvre lorsque le Serveur fournit à l'ACA le certificat anonyme BC. L'ACA peut savoir à quel moment il a produit cette signature (protocole de levée d'anonymat) et donc à qui est ce qu'il l'a fourni. La figure 5 schématise les détails des protocoles de certificat aveugle à anonymat révocable.
Il est à noter que dans ce cas, il convient d'obtenir une signature aveugle pour chaque session (il est ainsi impossible de relier deux sessions d'un même client). Il faut alors que le Client se connecte à l'ACA avant chaque début de session.
On retrouve le même problème (et les mêmes solutions) que pour le certificat anonyme dans le cas de plusieurs serveurs ou de plusieurs machines par client. Certificat de groupe
L'invention peut également mettre en oeuvre une signature de groupe.
Une signature de groupe permet aux membres d'un groupe de produire une signature telle que le vérificateur reconnaîtra cette signature comme ayant été produite par un membre du groupe, tout en ignorant de quel membre il s'agit. Cependant, une autorité de confiance a la possibilité de lever à tout moment cet anonymat et donc de révéler l'identité du signataire. De telles signatures sont bien souvent "non- corrélables" : il est impossible de déterminer si deux signatures ont été émises par la même personne ou non.
Dans tout schéma de signature de groupe, est attribuée au groupe une unique clé publique de groupe, tandis que sont attribués à chaque membre de ce groupe un identifiant et une clé privée qui lui sont propres. A l'aide de sa clé privée, un membre du groupe peut produire une signature de groupe d'un message de son choix, laquelle signature peut être vérifiée par une entité quelconque à l'aide de la clé publique de groupe. La vérification apprend seulement à cette entité que la signature a été produite par un membre du groupe, mais ne lui donne aucune information sur l'identifiant du membre qui a signé. En revanche, l'autorité de confiance dispose d'une information supplémentaire qui lui permet de retrouver l'identifiant de ce membre, et donc de lever cet anonymat à tout moment (on dit que l'autorité de confiance "ouvre" la signature). On se reportera aux documents [1], [2], [3] et [4] pour des schémas de signature de groupe.
Dans le cas de l'invention, l'ACA joue le rôle d'autorité de confiance. Au cours de la première étape, un Client va s'inscrire à unn groupe auprès de l'ACA en interagissant avec lui afin d'obtenir un certificat de membre GC (protocole d'enregistrement d'un membre).
L'ACA se garde les moyens d'ouvrir une signature le cas échéant.
L'étape de signature du jeton d'initialisation W1000 consiste à produire une signature de groupe S de cet élément (protocole de signature de groupe) soit S=SigGP (W1000). Ainsi, le signataire est anonyme au sein du groupe. Le Serveur a les moyens de vérifier qu'une signature a bien été émise par un membre du groupe (protocole de vérification de signature de groupe) mais sans pour autant savoir de quel membre il s'agit. Enfin, l'ACA, en temps qu'autorité de confiance, a les moyens d'ouvrir la signature (protocole d'ouverture de signature de groupe) pour lever l'anonymat et divulguer l'identité du signataire.
La figure 6 schématise les détails des protocoles de certificat de groupe. II est à noter que, du fait des propriétés d'anonymat et de non- reliabilité des signatures de groupe, il n'est pas nécessaire de s'enregistrer au groupe pour chaque session. Le fait d'être inscrit au groupe permet de faire autant de signature de groupe que le Client le désire sans pour autant que quelqu'un puisse relier deux de ses signatures. Ce certificat unique peut être utilisé chez plusieurs serveurs sans risque de pouvoir tracer le client. De même, un client possédant plusieurs machines n'aura pas besoin d'obtenir plusieurs certificats.
Remarque : Une propriété intéressante des approches basées sur les signatures de groupe et les signatures aveugles est qu'elles permettent de répartir les fonctions de génération de certificats et le pouvoir de levée d'anonymat entre deux ou plusieurs autorités. Selon ce principe, la levée de l'anonymat d'un utilisateur ne sera possible que si l'ensemble de ces autorités l'autorise. Ce processus est moins naturel dans le cas des certifications anonymes.
EXEMPLE DE REALISATION
On va maintenant décrire plus particulièrement l'application de la présente invention aux enchères électroniques.
L'application présentée ici pour illustrer le procédé conforme à l'invention appartient au domaine du commerce électronique sous la forme des ventes aux enchères sur Internet.
Le principe de ventes retenu est celui des enchères classiques où un article est mis aux enchères croissantes entre plusieurs enchérisseurs et pendant un temps déterminé. Cette réalisation s'appuie sur les technologies Java (applet, servlet, jsp) en architecture client-serveur avec un système de gestion de base de données relationnel. 1 Problème spécifique aux enchères résolu par le procédé 1.1 But
Le procédé offre une solution innovante pour sécuriser les enchères électroniques et permettre de réaliser des transactions en toute confiance.
Actuellement, les enchères en ligne ne présentent pas des niveaux de sécurité suffisants dans le cas d'enchères de grandes valeurs et pour des participants scrupuleux de préserver leur anonymat.
L'organisation de ventes aux enchères publiques de plusieurs milliers voire plusieurs millions d'euros réclament de nouveaux mécanismes.
La cryptographie utilisée dans le cadre de l'invention permet de répondre aux objectifs. Les informations transmises sont inintelligibles à des personnes extérieures à la transaction pour des raisons de confidentialité.
Le procédé assure la non-répudiation pour garantir que le client ne peut pas nier avoir fait acte de surenchère. Le procédé assure l'intégrité des données échangées.
Le procédé permet d'assurer l'identité d'un utilisateur par authentification. De plus, le procédé est rapide pour la prise en compte en temps réel des ordres d'enchères.
1.2 Innovation et avantages techniques du procédé appliqué aux enchères Le mécanisme de jetons signés avec anonymat est adapté aux enchères. Avec ce procédé, un acheteur peut être autorisé à participer aux enchères sans risque d'infractions liées à la divulgation de son identité. Personne ne peut se faire passer pour un autre et seuls les membres inscrits et autorisés peuvent participer aux enchères. Le système actuel connu de login/mot de passe est très répandu mais il ne présente pas toutes les garanties. Un programme informatique peut facilement capturer l'information transmise en clair sur Internet et offrir ainsi la possibilité à un usurpateur de voler un mot de passe. Si un protocole comme SSL permet de se prémunir contre ce type d'attaques, il ne permet pas en revanche de lutter contre les attaques à base de dictionnaires de mots de passe. En effet, ces attaques peuvent permettre de casser facilement des mots de passe trop courts et trop simples.
La caractéristique des jetons utilisés dans le procédé conforme à l'invention est son usage unique. Il ne peut servir que pour un ordre d'enchère et un seul, et ne dévoile aucune information sur son utilisateur. Il permet juste de vérifier que la requête transmise appartient bien à un utilisateur précis. Ici, un ordre d'enchère identifié par un mot de passe jetable est certifié appartenir à un acheteur particulier pour une valeur unique.
Les jetons sont envoyés par le client C au serveur d'enchères Se pour enchérir sur un produit. La présentation au début de l'enchère d'un premier jeton, noté W1000 pour le client 1 et X1000 pour le client 2, sert d'initialisation et de preuve pour la suite de la vente (voir figure 7). A partir de ce mécanisme de jetons, le principe est de signer le premier jeton envoyé pour enregistrer la demande de participation d'un client. Les jetons transmis pour enchérir sont vérifiés à partir de ce premier jeton d'initialisation, conformément au processus précédemment décrit. Les jetons suivants représentent les surenchères. Par exemple, si un client (client 1) participe à une enchère avec un prix de départ à 1000 et un pas à 100, il peut proposer d'enchérir à 1100 en transmettant un jeton (W999). Pour enchérir à 1400 et battre un autre acheteur monté à 1300, il devra révéler le jeton correspondant au prix de 1400 soit le jeton W996.
Ce processus est schématisé sur la figure 7. 2 Modélisation du système 2.1 Schéma général L'application de ventes aux enchères fait appel aux trois entités définies précédemment dans le procédé :
L'Autorité de Certification Anonyme (ACA) est placée sur un serveur d'anonymat (SA);
Le serveur Se fournisseur de services est ici le serveur d'enchères ;
Le client C. Nous trouvons également dans cette application un serveur de certificat (SC) qui fournit un certificat pour l'authentification forte.
Les fonctions principales du système d'enchères électroniques sont :
La phase préparatoire : qui consiste à mettre en vente, consulter et obtenir un certificat anonyme;
La phase d'enchères : qui consiste à demander et vérifier une participation à une vente, enchérir et vérifier renchérissement dans le but d'acquérir un article;
La phase conclusion : qui consiste à mettre un terme aux enchères, valider et identifier un gagnant en levant l'anonymat, clore la vente.
Chacune de ces fonctions va être détaillée par la suite. 2.2 Mise en vente et consultation
Cette fonction est schématisée figure 8. Phase du déroulement : Préparatoire ; Niveau de sécurité : Assurer l'authenticité du serveur d'enchères
Précondition : Connaître le site d'enchères ; Objectifs : Faire connaître les articles mis en vente ; - Acteur principal : Visiteur, Vendeur, Administrateur ;
Scénario typique : M.Martin est un collectionneur d'art, il décide d'acquérir une oeuvre mise en vente sur le site d'enchères. Il se connecte au site et demande à afficher le catalogue des articles à vendre. Parmi les articles, il s'intéresse plus particulièrement à une photographie intitulée Regards dont le prix de départ est 600 euros et vendu par M.LeVendeur. Il clique alors pour obtenir la fiche article, illustré à titre d'exemple sur la figure 9.
2.3 Obtention d'un certificat anonyme Cette fonction est schématisée sur la figure 10. - Phase du déroulement : Préparatoire; elle correspond à la première étape du procédé;
Niveau de sécurité : Obtenir l'anonymat avec la signature de groupe ;
Contrainte : Double certification ; - Précondition : Authentification forte (étape 1 du procédé), choisir un serveur d'anonymat (SA) ;
Objectifs : S'authentifier pour participer à une vente aux enchères tout en étant anonyme ;
Acteur principal : Visiteur et SA; - Scénario typique : M.Dupond est toujours décidé à participer à la vente aux enchères pour une œuvre d'art dont le prix de départ est 500.000 euros. Il souhaite rester anonyme pour cette vente afin de ne pas révéler ses moyens financiers ni son intérêt pour le type d'œuvre à vendre, et, s'il gagne l'enchère, il ne veut pas que l'on sache qu'il devient le nouveau propriétaire. Rester anonyme tout en signant est rendu possible grâce à la signature de groupe. M.Dupond fait donc appel aux services d'une autorité de certification délivrant une signature de groupe. Il s'inscrit à un groupe qui vérifie son identité avant de lui fournir les moyens de créer ses clés et de l'enregistrer comme membre certifié. Un tel processus est schématisé figure 11.
2.4 Demande de participation avec certificat et autorisation Cette fonction est schématisée figure 12. - Phase du déroulement : Enchère ; elle fait partie de la troisième étape du procédé;
Niveau de sécurité : Certificat et applet signée de génération de jetons d'enchères;
Précondition : Pour le client, avoir un certificat, avoir choisi un article, autoriser le chargement des applets signées; pour le serveur d'enchères, avoir obtenu les moyens de vérifier une authentification anonyme (deuxième étape du procédé);
Objectifs : Participer à une vente aux enchères ; Acteur principal : Client ; - Scénario typique : Afin de participer à l'enchère, M.Dupond présente sa demande à l'aide d'un jeton signé. Ce premier jeton, noté W1000 pour M.Dupond et X1000 pour un autre client (voir figure 13), sert d'initialisation et de preuve pour la suite de la vente. Ce premier jeton est généré et signé par le client avec sa clé privée grâce à une applet transmise par le site d'enchère. Le jeton est associé aux paramètres de la vente, identifiant de l'article, prix actuel et valeur du pas. Pour M.Dupond, la signature est anonyme grâce à la signature de groupe.
2.5 Participation à une vente aux enchères Cette fonction est schématisée figure 14.
Phase du déroulement : Enchère ; elle fait partie de la troisième étape du procédé;
Niveau de sécurité : Le jeton assure l'authenticité, l'intégrité et la confidentialité de l'ordre d'enchère ; - Précondition : Etre inscrit à la vente, le jeton possède une filiation ;
Objectifs : Soumettre un ordre d'enchère pour remporter la vente ; Acteur principal : Client ;
Scénario typique : M.Martin participe à la vente aux enchères de la photographie qu'il a choisi avec un prix de départ à 600 euros et un pas à 10 euros. Il est le premier enchérisseur et il s'engage à enchérir à 610 euros en transmettant un jeton (W999). Au cours de l'enchère, un deuxième client augmente le prix à 620 euros. M.Martin est prêt à mettre plus et clique sur le bouton pour surenchérir à 630 euros. Il transmet alors le jeton d'indice 997, noté W997. En effet, comme décrit précédemment, chaque jeton correspond à une valeur calculée en fonction du prix de départ et du pas de l'enchère.
Dans cette vente, l'indice 999 représente la valeur 610 euros, 998-620, 997-630, 996-640, ... ;
Un tel processus est schématisé figure 15.
2.6 Traitement des ordres d'enchères Cette fonction est schématisé figure 16.
Phase du déroulement : Enchère ; elle fait partie de la troisième étape du procédé;
Niveau de sécurité : Le jeton assure l'authenticité du client et l'intégrité des données ; - Précondition : Avoir un jeton d'initialisation pour les enchères d'un client particulier sur un article ;
Objectifs : Comparer les ordres d'enchères, enregistrer les ordres et informer de l'évolution des enchères ; Acteur principal : Client ; - Scénario typique : Lorsque M.Martin clique sur le bouton pour enchérir, un jeton correspondant au prix est envoyé au serveur d'enchères. Côté serveur, le jeton permet de retrouver les informations nécessaires à l'ordre d'enchère, c'est-à-dire sa valeur, son propriétaire (M.Martin) et l'article visé. Pour connaître la position de M.Martin, son ordre est comparé aux ordres des autres clients. La proposition de M.Martin est enregistrée et le prix de la photo est actualisé. Ce processus est schématisé figure 17.
2.7 Conclusion de la vente Cette fonction est schématisé figure 18.
Phase du déroulement : Conclusion de la vente ; elle comporte la quatrième étape du procédé;
Niveau de sécurité : Identifier le gagnant et lever l'anonymat du gagnant en cas de signature de groupe ;
Objectifs : Déterminer un gagnant et clore la transaction ; Acteur principal : Client, Vendeur, SA, Tiers de confiance ; Scénario typique : Le temps de la vente écoulé, le système détermine si M.Dupond a gagné ou non l'enchère en comparant les différentes propositions. L'offre de 800.000 euros est la plus forte et M.Dupond (anonyme) remporte l'œuvre d'art. Les autres clients sont prévenus qu'ils ont perdu. Le vendeur est informé que son article a trouvé un acheteur. Le Tiers de Confiance est alors chargé de lever l'anonymat de M.Dupond et de clore la transaction en tant qu'intermédiaire entre M.Dupond et le vendeur. Ce processus est schématisé figure 19. 2.8 Remarques
- Inscription pour la participation à une vente : L'inscription à une vente est liée à une session. Il est donc nécessaire de réinitialiser l'inscription en cas de déconnexion ou de changement de session ;
- Usage des certificats : Les certificats d'authentification forte et les certificats anonymes sont multi-usages. Il est donc possible d'utiliser un certificat pour plusieurs ventes sans avoir à renouveler les demandes à chaque vente, sauf en cas de révocation ou d'expiration du certificat; - Propriétés à la demande du certificat anonyme *. Lors de la connexion entre un client et le site serveur d'anonymat, la confidentialité et l'intégrité des informations transmises et la garantie d'anonymat du client vis-à-vis de l'extérieur sont assurées par un protocole de communication par exemple SSL ; - Anticipation pour une première participation : La configuration de l'environnement technique du poste client (applet cryptographique signée) et les démarches d'obtention de certificats réclament une préparation à la participation à une vente. 3 Spécification de l'application d'enchères
Cette partie décrit succinctement l'API pour les services de l'application aux niveaux suivants :
Demande d'un certificat anonyme et de participation à une vente;
Contrôle de demande de participation; Enchère;
Vérification d'enchère; Conclusion de la vente. Les étapes indiquées par une * sont considérées comme basiques dans le cadre du procédé conforme à l'invention.
3.1 Demande d'un certificat anonyme et de participation à une vente
- S'authentifier de manière forte auprès de l'ACA* - Générer les clés*
- Envoyer la clé publique à l'ACA*
- Obtenir un certificat anonyme auprès de l'ACA*
- Générer les jetons*
- Stocker les jetons* - Signer le jeton d'initialisation et l'id article*
- Transmettre le jeton signé, le certificat et l'id article signé*
- Recevoir la confirmation
- Afficher la confirmation
3.2 Contrôle de demande de participation - Récupérer les moyens de vérifier une authentification anonyme auprès de l'ACA*
- Recevoir les données de l'applet
- Vérifier la signature avec les moyens de l'ACA*
- Se connecter à la base de données - Enregistrer les données jeton, certificat, id article
- Sélectionner dans la base le prix max de l'article
- Transmettre la confirmation
3.3 Enchère - Actualiser le prix max
- Calculer le jeton par rapport au prix supérieur prixsup = prixmax + pas j = (prixsup - prixdedepart)/pas i = nombretotaldejetons - j
- Transmettre le jeton*
- Recevoir la réponse 3.4 Vérification d'enchère - Décompter le temps de la vente
- Recevoir le jeton (Wj)*
- Vérifier le jeton (trouver dans la base Wk tel que h'(Wj) = Wk)*
- Sélectionner les données de la base pour Wk
- Sélectionner le prix max de l'id article - Calculer le prix correspondant au jeton reçu Wj prix de Wj = prix de Wk +(l* pas)
- Comparer le prix max au prix de Wi
- Enregistrer le prix de Wj (UPDATE)
- Répondre au client sur sa situation 3.5 Conclusion de la vente
- Détecter la fin de l'enchère
- Déterminer l'offre la plus haute
- Lever l'anonymat*
- Informer l'acheteur gagnant - Informer le vendeur
4 Organisation technique
4.1 Architecture client - serveur
Cette architecture est schématisée figure 20. On y retrouve un navigateur Client, un Serveur ACA et un Serveur Se enchères (ces derniers étant chacun associé à une base de données spécifiques) aptes à mettre en oeuvre les étapes précitées.
4.2 Outils de prototypage : Base de données, serveur d'application et Plug-in Java La base de données utilisée par les inventeurs pour un prototypage de cette application est une base Oracle 8i. Oracle est un SGBD (système de gestion de bases de données) relationnel édité par la société du même nom. Oracle dispose d'un langage permettant la définition et la manipulation des données : le langage SQL (Structured Query Language), qui est devenu le langage normalisé dans le domaine des bases de données relationnelles. SQL*PLUS est l'interface utilisateur d'Oracle qui permet d'utiliser interactivement le langage SQL sur une instance Oracle. Le langage de programmation et les technologies utilisées pour l'implantation sont Java. L'application est gérée par le produit d'IBM WebSphere 3.5. WebSphere Application Server permet de réaliser des transactions et des interactions Web. Il fournit une plate-forme portable de déploiement d'applications Web Java, axée sur la prise en charge et l'exécution de serviets, de JavaBeans et de fichiers Java Server Pages (JSP). C'est une interface avec le serveur Web pour gérer les requêtes client portant sur les ressources côté serveur et pour les acheminer vers le serveur d'applications en vue de leur traitement. L'outil utilisé dans WebSphere est le moteur de servlet. Il s'exécute à l'intérieur du serveur d'applications et gère les requêtes relatives aux serviets, aux fichiers Java Server Pages (JSP) et aux applications Web qui les contiennent.
Le poste client a été testé sur un système Windows avec le Plug- in Java. Le Plug-in (fournit par Sun) permet d'actualiser la version de la JVM du navigateur (IE ou Netscape). Le Java-plugin remplace le Java Runtime par défaut du navigateur par le JRE de Sun.
Bien entendu la présente invention n'est pas limitée au mode de réalisation particulier qui vient d'être décrit mais s'étend à toute variante conforme à son esprit. REFERENCES [1] G. Ateniese, J. Camenisch, M. Joye, G. Tsudik. A practical and provably secure coalition-résistant group signature scheme. In L. Bellare, editor, Advances in Cryptology - Crypto 2000, volume 1880 of LNCS, pages 255-270. Springer-Verlag, 2000. [2] S. Canard, M Girault. Implementing group signature schemes with smart cards. conférence CARDIS 2002.
[3] J. Camenisch, M. Michels. A group signature scheme based on an RSA-variant. Proceedings of Eurocrypt'98, volume 1514 of LNCS. Springer-Verlag, 1998.
[4] J. Camenisch, M, Stadler. Efficient group signature schemes for large groups. Proceedings of Crypto'97, volume 1296 of LNCS, pages 410-424. Springer-Verlag, 1997.
[5] K.Q. Nguyen, J. Traoré. "An Online Public Auction Protocol Protecting Bidder Privacy". Information Security and Privacy, 5th Australasian Conference-ACISP 2000, pages 427-442. Springer-Verlag, 2000.
[6] J Camenisch, U. Maurer, M. Stadler. Digital payment Systems with passive anonymity-revoking trustées. Proceedings of ESORICS'96, volume 1146 of LNCS, pages 33-43. Springer-Verlag, 1996.
[7] J Camenisch, U. Maurer, M. Stadler. Digital payment Systems with passive anonymity-revoking trustées. Journal of Computer Security, vol. 5, number 1, IOS Press, 1997.
[8] A. de Solages, J. Traoré. An Efficient fair off-line electronic cash System with extensions to checks and wallet with observers, Proceedings of Financial Crypto'98, volume 1465 of LNCS, pages 275- 295. Springer-Verlag, 1998.
[9] A. de Solages et J. Traoré, Procédé de signature numérique juste, n° 98 02197, CNET/02959, dépôt du 24/02/98. [10] Y. Frankel, Y. Tsiounis, M. Yung. Indirect discourse proofs: achieving fair off-line electronic cash. Proceedings of Asiacrypt'96, volume 1136 of LNCS, pages 244-251. Springer-Verlag, 1996.
[11] Y. Frankel, Y. Tsiounis et M. Yung . "Fair off-line cash made easy". Proceedings of Asiacrypt'98, volume 1514 of LNCS. Springer- Verlag, 1998.
[12] KOBAYASHI K ; MORITA H : "Efficient sealed-bid auction by using one-way functions", IEICE Transactions on fundamentals of electronics, communications and computer sciences, institute of electronics information and comm. eng., vol. e84-A, n° 1, 1 janvier 2001 (2001-01-01), pages 289-294.
[13] SUZUKI K ; KOBAYASHI K ; MORITA H : "Efficient sealed- bid auction using hash chain", Information security and cryptology - ICISC 2000. Third international conférence. Proceedings (lecture notes in computer science, vol. 2015, Springer veriag), 9 décembre 2000
(2000-12-09), pages 183-191.
[14] BYOUNGCHEON LEE ; KWANGJO KIM ; JOONGSOO MA : "Efficient public auction wih one-time registration and public verifiability", Indocrypt 2001, second international conférence on cryptology in India, 16-20 décembre 2001, pages 162-174.

Claims

REVENDICATIONS
1. Procédé d'accès à un service avec authentification rapide et anonymat révocable, caractérisé par le fait qu'il comprend les étapes consistant à : i) identifier et enregistrer un Client (C) et lui fournir des moyens lui permettant de s'authentifier auprès d'une Autorité de Certification Anonyme (ACA), 11) authentifier le Client auprès de I' Autorité de Certification Anonyme sur la base des moyens fournis en i) et fournir des moyens lui permettant de s'authentifier de manière anonyme auprès d'un Serveur (Se), iii) authentifier le Client par la production d'une signature anonyme et ouvrir et maintenir une session d'authentification anonyme auprès d'un Serveur (Se), et iv) permettre sélectivement un contact entre le Serveur (Se) et l'Autorité de Certification Anonyme (ACA) pour lever l'anonymat du Client (C) sur la base de la signature fournie à l'étape iii).
2. Procédé selon la revendication 1, caractérisé par le fait qu'il comprend une étape additionnelle d'échange entre l'Autorité de
Certification Anonyme (ACA) et le Serveur (Se) préalable à l'étape ii) par laquelle le Serveur (Se) présente à ladite Autorité (ACA) une requête d'obtention de moyens permettant de vérifier l'authentification anonyme fournie par un Client (C).
3. Procédé selon l'une des revendications 1 ou 2, caractérisé par le fait que l'étape iii) comprend trois phases :
. une première phase dans laquelle le Client (C) calcule un ensemble de données, formé d'une suite de jetons, l'un de ceux-ci permettant d'ouvrir une session, tandis que les autres permettent de la maintenir, . une deuxième phase dans laquelle le Client (C) s'engage fortement sur la suite de jetons auprès du Serveur, et
. une troisième phase de maintien de la session à l'aide de la suite de jetons.
4. Procédé selon la revendication 3, caractérisé par le fait que tous les jetons sont à usage unique et fortement dépendants les uns des autres.
5. Procédé selon l'une des revendications 3 ou 4, caractérisé par le fait que l'étape de génération des jetons met en oeuvre deux primitives cryptographiques : une fonction de hachage et un nombre aléatoire.
6. Procédé selon la revendication 5, caractérisé par le fait que le premier jeton est obtenu en appliquant la fonction de hachage au nombre aléatoire, le deuxième jeton est obtenu en appliquant à nouveau la fonction de hachage au premier jeton obtenu, et ainsi de suite pour obtenir n jetons : H(W0)=Wι ; H(Wn-ι)=Wn.
7. Procédé selon l'une des revendications 3 à 6, caractérisé par le fait que la deuxième phase comprend l'obtention d'une signature anonyme d'un jeton d'initialisation Wn permettant l'authentification d'un Client par le Serveur.
8. Procédé selon l'une des revendications 3 à 7, caractérisé par le fait que des informations, telles qu'une valeur numéraire, sont associées au jeton d'initialisation.
9. Procédé selon l'une des revendications 3 à 8, caractérisé par le fait qu'à chaque nouvelle authentification le Client (C) transmet au Serveur (Se) un jeton de rang inférieur d'au moins une unité à celui précédemment utilisé.
10. Procédé selon l'une des revendications 3 à 9, caractérisé par le fait qu'à chaque nouvelle authentification le Client (C) transmet au
Serveur (Se) un jeton Wj dont le rang i est choisi représentatif de la valeur d'une opération, par exemple du nombre de pas d'une enchère.
11. Procédé selon l'une des revendications 1 à 10, caractérisé par le fait qu'il est appliqué à des enchères et que les étapes de surenchérissement par le Client (C) sont opérées par envois successifs de jetons de rang inférieur.
12. Procédé selon l'une des revendications 1 à 11, caractérisé par le fait qu'il met en oeuvre une signature de groupe, par association de plusieurs identifiants et clés privées respectives, à une unique clé publique de groupe.
13. Procédé selon l'une des revendications 1 à 12, caractérisé par le fait qu'il met en oeuvre une signature aveugle.
14. Procédé selon l'une des revendications 12 et 13, caractérisé par le fait que les pouvoirs de levée d'anonymat sont répartis entre au moins deux autorités.
15. Système apte à permettre l'ouverture et le maintien d'une session d'authentification garantissant la non répudiation, caractérisé par le fait qu'il comprend des moyens adaptés pour la mise en œuvre de trois phases :
. une première phase dans laquelle un Client (C) calcule un ensemble de données, formé d'une suite de jetons, l'un de ceux-ci permettant d'ouvrir une session, tandis que les autres permettent de la maintenir, . une deuxième phase dans laquelle le Client s'engage fortement sur la suite de jetons auprès d'un Serveur (se), et
. une troisième phase de maintien de la session à l'aide de la suite de jetons.
16. Système selon la revendication 15, caractérisé par le fait que l'étape de génération des jetons met en oeuvre deux primitives cryptographiques : une fonction de hachage et un nombre aléatoire.
17. Système selon l'une des revendications 15 à 16, caractérisé par le fait qu'il met en oeuvre une signature de groupe, par association de plusieurs identifiants et clés privées respectives, à une unique clé publique de groupe.
18. Système selon l'une des revendications 15 à 17, caractérisé par le fait qu'il met en oeuvre une signature aveugle.
19. Système selon l'une des revendications 15 à 18, caractérisé par le fait que les pouvoirs de levée d'anonymat sont répartis entre au moins deux autorités.
EP03782564A 2002-11-14 2003-11-14 Procede et systeme avec authentification, anonymat revocable et non repudiation Withdrawn EP1561302A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0214230 2002-11-14
FR0214230A FR2847401A1 (fr) 2002-11-14 2002-11-14 Procede d'acces a un service avec authentification rapide et anonymat revocable et systeme d'ouverture et de maintien de session
PCT/FR2003/003380 WO2004047362A1 (fr) 2002-11-14 2003-11-14 Procede et systeme avec authentification, anonymat revocable et non repudiation

Publications (1)

Publication Number Publication Date
EP1561302A1 true EP1561302A1 (fr) 2005-08-10

Family

ID=32187588

Family Applications (1)

Application Number Title Priority Date Filing Date
EP03782564A Withdrawn EP1561302A1 (fr) 2002-11-14 2003-11-14 Procede et systeme avec authentification, anonymat revocable et non repudiation

Country Status (4)

Country Link
US (1) US7840813B2 (fr)
EP (1) EP1561302A1 (fr)
FR (1) FR2847401A1 (fr)
WO (1) WO2004047362A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN120811769A (zh) * 2025-09-08 2025-10-17 浪潮电子信息产业股份有限公司 身份认证方法、系统、电子设备、存储介质及程序产品

Families Citing this family (70)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4250429B2 (ja) * 2003-01-24 2009-04-08 キヤノン株式会社 連鎖型署名作成装置、及びその制御方法
US9412123B2 (en) 2003-07-01 2016-08-09 The 41St Parameter, Inc. Keystroke analysis
US7860243B2 (en) * 2003-12-22 2010-12-28 Wells Fargo Bank, N.A. Public key encryption for groups
US8495361B2 (en) * 2003-12-31 2013-07-23 International Business Machines Corporation Securely creating an endorsement certificate in an insecure environment
US7644278B2 (en) * 2003-12-31 2010-01-05 International Business Machines Corporation Method for securely creating an endorsement certificate in an insecure environment
US10999298B2 (en) 2004-03-02 2021-05-04 The 41St Parameter, Inc. Method and system for identifying users and detecting fraud by use of the internet
US20060010072A1 (en) * 2004-03-02 2006-01-12 Ori Eisen Method and system for identifying users and detecting fraud by use of the Internet
AU2004201058B1 (en) * 2004-03-15 2004-09-09 Lockstep Consulting Pty Ltd Means and method of issuing Anonymous Public Key Certificates for indexing electronic record systems
US7899184B2 (en) * 2004-09-02 2011-03-01 Pisaramedia Oy Ends-messaging protocol that recovers and has backward security
US8402141B2 (en) * 2004-09-28 2013-03-19 International Business Machines Corporation Gracefully reestablishing an expired browser session
US7661128B2 (en) 2005-03-31 2010-02-09 Google Inc. Secure login credentials for substantially anonymous users
JP2007004461A (ja) * 2005-06-23 2007-01-11 Nec Corp サービス提供システム、アウトソーシング業者装置、サービス提供方法およびプログラム
CN1937496A (zh) * 2005-09-21 2007-03-28 日电（中国）有限公司 可延展伪名证书系统和方法
US8874477B2 (en) 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
US8938671B2 (en) 2005-12-16 2015-01-20 The 41St Parameter, Inc. Methods and apparatus for securely displaying digital images
US11301585B2 (en) 2005-12-16 2022-04-12 The 41St Parameter, Inc. Methods and apparatus for securely displaying digital images
EP1964306B1 (fr) * 2005-12-19 2012-06-20 Telecom Italia S.p.A. Schema de signature de groupe d'efficacite renforcee en particulier dans une procedure conjointe
US8171293B2 (en) * 2005-12-30 2012-05-01 Apple Inc. Receiver non-repudiation via a secure device
WO2007095691A1 (fr) * 2006-02-24 2007-08-30 Commonwealth Scientific And Industrial Research Organisation Authentification anonyme
US8151327B2 (en) 2006-03-31 2012-04-03 The 41St Parameter, Inc. Systems and methods for detection of session tampering and fraud prevention
US7958544B2 (en) 2006-07-21 2011-06-07 Google Inc. Device authentication
ATE464612T1 (de) * 2006-08-04 2010-04-15 Rolf Zahnd Verfahren zur anonymen analyse authentifizierender identitäts-codes eines benutzers oder eines objekts
GB0621189D0 (en) 2006-10-25 2006-12-06 Payfont Ltd Secure authentication and payment system
EP2118809A4 (fr) * 2007-02-02 2012-08-01 Telcordia Tech Inc Procédé et système permettant d'autoriser et d'assigner des certificats numériques sans perte de confidentialité
US8443191B2 (en) 2007-04-09 2013-05-14 Objective Interface Systems, Inc. System and method for accessing information resources using cryptographic authorization permits
WO2008146667A1 (fr) * 2007-05-24 2008-12-04 Nec Corporation Système d'authentification anonyme et procédé d'authentification anonyme
US7877331B2 (en) * 2007-09-06 2011-01-25 King Fahd University Of Petroleum & Minerals Token based new digital cash protocols with combined blind digital signature and pseudonym authentication
US9060012B2 (en) * 2007-09-26 2015-06-16 The 41St Parameter, Inc. Methods and apparatus for detecting fraud with time based computer tags
US8838803B2 (en) * 2007-12-20 2014-09-16 At&T Intellectual Property I, L.P. Methods and apparatus for management of user presence in communication activities
AU2008356253A1 (en) * 2008-05-16 2009-11-19 Objective Interface Systems, Inc. System and method that uses cryptographic certificates to define groups of entities
US8380981B2 (en) 2008-05-16 2013-02-19 Objective Interface Systems, Inc. System and method that uses cryptographic certificates to define groups of entities
US9390384B2 (en) * 2008-07-01 2016-07-12 The 41 St Parameter, Inc. Systems and methods of sharing information through a tagless device consortium
US9621341B2 (en) * 2008-11-26 2017-04-11 Microsoft Technology Licensing, Llc Anonymous verifiable public key certificates
US8458477B2 (en) * 2008-12-01 2013-06-04 Novell, Inc. Communication with non-repudiation
US8806214B2 (en) 2008-12-01 2014-08-12 Novell, Inc. Communication with non-repudiation and blind signatures
KR20100066169A (ko) * 2008-12-09 2010-06-17 한국전자통신연구원 익명 인증을 이용한 개인 정보 관리 시스템 및 방법
US9112850B1 (en) 2009-03-25 2015-08-18 The 41St Parameter, Inc. Systems and methods of sharing information through a tag-based consortium
JP2012527678A (ja) * 2009-05-20 2012-11-08 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ ポータブルなユーザー評判を可能にする方法および装置
US9608826B2 (en) * 2009-06-29 2017-03-28 Jpmorgan Chase Bank, N.A. System and method for partner key management
US8688591B2 (en) * 2009-08-06 2014-04-01 International Business Machines Corporation Anonymous separation of duties with credentials
US8862879B2 (en) * 2009-10-13 2014-10-14 Sergio Demian LERNER Method and apparatus for efficient and secure creating, transferring, and revealing of messages over a network
WO2011047085A2 (fr) * 2009-10-13 2011-04-21 Certimix, Inc. Procédé et appareil de création, de transfert et de publication efficaces et sécurisés de messages sur un réseau
KR101284114B1 (ko) * 2009-11-18 2013-07-10 한국전자통신연구원 익명 ｉｄ 관리 장치 및 그 방법, 익명 ｉｄ 관리 시스템 및 이를 이용한 서비스 제공 방법
FR2960671B1 (fr) * 2010-06-01 2020-01-10 Institut Telecom-Telecom Paris Tech Procede de securisation de donnees numeriques et d'identites notamment au sein de processus utilisant des technologies de l'information et de la communication
WO2012054646A2 (fr) 2010-10-19 2012-04-26 The 41St Parameter, Inc. Moteur de risque variable
US10754913B2 (en) 2011-11-15 2020-08-25 Tapad, Inc. System and method for analyzing user device information
US9571481B1 (en) * 2011-11-30 2017-02-14 Amazon Technologies, Inc. Once only distribution of secrets
US10433161B2 (en) * 2012-01-30 2019-10-01 Telefonaktiebolaget Lm Ericsson (Publ) Call handover between cellular communication system nodes that support different security contexts
US9633201B1 (en) 2012-03-01 2017-04-25 The 41St Parameter, Inc. Methods and systems for fraud containment
US9160535B2 (en) * 2012-03-19 2015-10-13 Dell Inc Truly anonymous cloud key broker
US9521551B2 (en) 2012-03-22 2016-12-13 The 41St Parameter, Inc. Methods and systems for persistent cross-application mobile device identification
WO2014022813A1 (fr) 2012-08-02 2014-02-06 The 41St Parameter, Inc. Systèmes et procédés d'accès à des enregistrements via des localisateurs de dérivé
WO2014078569A1 (fr) 2012-11-14 2014-05-22 The 41St Parameter, Inc. Systèmes et procédés d'identification globale
US10397201B2 (en) 2013-03-15 2019-08-27 Entit Software Llc Sending encrypted data to a service provider
FR3006782A1 (fr) * 2013-06-11 2014-12-12 France Telecom Procede et systeme de delegation d'un calcul d'une valeur de couplage bilineaire a un serveur de calcul
US10902327B1 (en) 2013-08-30 2021-01-26 The 41St Parameter, Inc. System and method for device identification and uniqueness
CN103607284B (zh) * 2013-12-05 2017-04-19 李笑来 身份认证方法及设备、服务器
US9779174B2 (en) * 2014-05-11 2017-10-03 Sap Se Framework for anonymous reporting of social incidents
US10091312B1 (en) 2014-10-14 2018-10-02 The 41St Parameter, Inc. Data structures for intelligently resolving deterministic and probabilistic device identifiers to device profiles and/or groups
US10498537B2 (en) * 2016-08-01 2019-12-03 Institute For Development And Research In Banking Technology (Drbt) System and method for providing secure collaborative software as a service (SaaS) attestation service for authentication in cloud computing
US10796591B2 (en) * 2017-04-11 2020-10-06 SpoonRead Inc. Electronic document presentation management system
US10798129B2 (en) 2017-07-10 2020-10-06 Ebay Inc. Constraint-based multiuse certificates
US11223605B2 (en) * 2018-02-05 2022-01-11 Onboard Security, Inc. Method and system for connected vehicle communication
US11164206B2 (en) * 2018-11-16 2021-11-02 Comenity Llc Automatically aggregating, evaluating, and providing a contextually relevant offer
FR3091107A1 (fr) * 2018-12-24 2020-06-26 Orange Procédé et système de génération de clés pour un schéma de signatures anonymes
PT115479B (pt) 2019-04-29 2021-09-15 Mediceus Dados De Saude Sa Sistema de computador e método de operação para gerir dados pessoais anonimizados
US10790990B2 (en) 2019-06-26 2020-09-29 Alibaba Group Holding Limited Ring signature-based anonymous transaction
US11451519B2 (en) * 2019-11-25 2022-09-20 Electronics And Telecommunications Research Institute Anonymous credential authentication system and method thereof
US12238101B2 (en) * 2021-03-09 2025-02-25 Oracle International Corporation Customizing authentication and handling pre and post authentication in identity cloud service
KR102568418B1 (ko) * 2021-08-26 2023-08-18 하이파이브랩 주식회사 다중 서명을 지원하는 전자 인증 시스템 및 방법

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6055518A (en) * 1996-02-01 2000-04-25 At&T Corporation Secure auction systems
US5815665A (en) * 1996-04-03 1998-09-29 Microsoft Corporation System and method for providing trusted brokering services over a distributed network
US6154841A (en) * 1996-04-26 2000-11-28 Canon Kabushiki Kaisha Digital signature method and communication system
US6397329B1 (en) * 1997-11-21 2002-05-28 Telcordia Technologies, Inc. Method for efficiently revoking digital identities
US6363365B1 (en) * 1998-05-12 2002-03-26 International Business Machines Corp. Mechanism for secure tendering in an open electronic network
JP2001202013A (ja) * 2000-01-21 2001-07-27 Nec Corp 匿名参加権限管理システム
US7383206B2 (en) * 1999-02-19 2008-06-03 Ariba, Inc. Method and apparatus for multiple variable bidding in an online auction
CA2403488C (fr) * 2000-03-17 2011-10-18 Decode Genetics Ehf Systeme automatique de protection de l'identite avec surveillance a distance par une tierce partie
DE60114833T2 (de) * 2000-03-24 2006-04-13 Dategrity Corp., Bellevue Überprüfbare, geheime mischung von verschlüsselten daten wie z. b. elgamal-verschlüsselte daten für gesicherte mehrinstanzwahlen
US20030158960A1 (en) * 2000-05-22 2003-08-21 Engberg Stephan J. System and method for establishing a privacy communication path
US20050187856A1 (en) * 2004-01-30 2005-08-25 Rabenold Nancy J. Anonymous bidding system
US7360080B2 (en) * 2000-11-03 2008-04-15 International Business Machines Corporation Non-transferable anonymous credential system with optional anonymity revocation
US7251833B2 (en) * 2000-12-29 2007-07-31 International Business Machines Corporation Digital media delivery with local cache and streaming tokens
US20020087473A1 (en) * 2000-12-29 2002-07-04 Shlomi Harif System, method and program for creating an authenticatable, non-repudiatable transactional identity in a heterogeneous network
US8005965B2 (en) * 2001-06-30 2011-08-23 International Business Machines Corporation Method and system for secure server-based session management using single-use HTTP cookies
US20030014631A1 (en) * 2001-07-16 2003-01-16 Steven Sprague Method and system for user and group authentication with pseudo-anonymity over a public network
US20030028470A1 (en) * 2001-07-26 2003-02-06 International Business Machines Corporation Method for providing anonymous on-line transactions
US7234059B1 (en) * 2001-08-09 2007-06-19 Sandia Corporation Anonymous authenticated communications
GB2380368B (en) * 2001-09-27 2005-06-22 Ibm A method and system for communication via a computer network
US7392390B2 (en) * 2001-12-12 2008-06-24 Valve Corporation Method and system for binding kerberos-style authenticators to single clients
US20030190046A1 (en) * 2002-04-05 2003-10-09 Kamerman Matthew Albert Three party signing protocol providing non-linkability
US7805606B2 (en) * 2002-07-29 2010-09-28 Bea Systems, Inc. Computer system for authenticating a computing device

Non-Patent Citations (1)

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

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN120811769A (zh) * 2025-09-08 2025-10-17 浪潮电子信息产业股份有限公司 身份认证方法、系统、电子设备、存储介质及程序产品

Also Published As

Publication number Publication date
WO2004047362A1 (fr) 2004-06-03
US20060155985A1 (en) 2006-07-13
US7840813B2 (en) 2010-11-23
FR2847401A1 (fr) 2004-05-21

Similar Documents

Publication Publication Date Title
EP1561302A1 (fr) Procede et systeme avec authentification, anonymat revocable et non repudiation
EP2116000B1 (fr) Procéée d'authentification unique d'un utilisateur auprès de fournisseurs de service
EP1368930B1 (fr) Authentification cryptographique par modules ephemeres
EP1459479A2 (fr) Systeme cryptographique de signature de groupe
EP1461898A1 (fr) Procede et dispositif de signature anonyme au moyen d une clef privee partagee
WO2011117486A1 (fr) Infrastructure non hierarchique de gestion de bi-cles de securite de personnes physiques
EP1612991A1 (fr) Procédé et système de vote électronique en réseau à haute sécurité
CN110533417B (zh) 一种数字资产管理装置、发行方法及系统
EP1908215A1 (fr) Procédé de contrôle de transactions sécurisées mettant en oeuvre un dispositif physique unique à bi-clés multiples, dispositif physique, système et programme d'ordinateur correspondants
JP5084746B2 (ja) ピアツーピアでのカルマおよび信頼を確立する方法ならびにその装置
Cha et al. A blockchain-based privacy preserving ticketing service
WO2003003649A1 (fr) Procede d'authentification cryptographique
WO2007012583A1 (fr) Procede de controle de transactions securisees mettant en oeuvre un dispositif physique unique, dispositif physique, systeme, et programme d'ordinateur correspondants
WO2003060841A1 (fr) Procede cryptographique de revocation a l'aide d'une carte a puce
EP3262553B1 (fr) Procede de transaction sans support physique d'un identifiant de securite et sans jeton, securise par le decouplage structurel des identifiants personnels et de services
EP3672193A1 (fr) Procédé et système d'authentification d'un terminal client par un serveur cible, par triangulation via un serveur d'authentification
EP4078893B1 (fr) Procédé et dispositif de contrôle d'accès anonyme à une plateforme collaborative d'anonymisation
EP2689552B1 (fr) Infrastructure non hiérarchique de gestion de bi-clés de sécurité de personnes physiques ou d'éléments (igcp/pki).
van Oorschot Changed the World
FR3154209A1 (fr) Procédé de mise en œuvre d’une transaction entre un premier équipement de preuve et un deuxième équipement de vérification.
WO2025181246A1 (fr) Procédés et dispositifs de gestion de la révocation d'accréditations cryptographiques
WO2022096841A1 (fr) Procede d'authentification securise par le decouplage structurel des identifiants personnels et de services
EP4674088A1 (fr) Procédé de delivrance d'une autorisation d'accès pour un individu et procédé de vérification
WO2012001272A1 (fr) Procede d'authentification permettant de renforcer l'anonymat entre un fournisseur d'identites et un fournisseur de services
Ahmed et al. Post-Session Authentication

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: 20050517

AK Designated contracting states

Kind code of ref document: A1

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

AX Request for extension of the european patent

Extension state: AL LT LV MK

DAX Request for extension of the european patent (deleted)
RIN1 Information on inventor provided before grant (corrected)

Inventor name: TRAORE, JACQUES

Inventor name: MALVILLE, ERIC

Inventor name: GUILLOTEAU, STEPHANE

Inventor name: CANARD, SEBASTIEN

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: 20120601