WO2013088024A1 - Accreditations anonymes - Google Patents

Accreditations anonymes Download PDF

Info

Publication number
WO2013088024A1
WO2013088024A1 PCT/FR2012/052780 FR2012052780W WO2013088024A1 WO 2013088024 A1 WO2013088024 A1 WO 2013088024A1 FR 2012052780 W FR2012052780 W FR 2012052780W WO 2013088024 A1 WO2013088024 A1 WO 2013088024A1
Authority
WO
WIPO (PCT)
Prior art keywords
attributes
signature
electronic device
electronic
user
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.)
Ceased
Application number
PCT/FR2012/052780
Other languages
English (en)
Inventor
Sébastien CANARD
Roch LESCUYER
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 WO2013088024A1 publication Critical patent/WO2013088024A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements

Definitions

  • the invention relates to the field of anonymous accreditation systems for accessing services.
  • a trusted organization issues, for certain users, certified accreditations relating to one or more attributes of this user.
  • Such an organization may be, for example, a town hall issuing certified accreditations consisting of identity cards, which have a number of attributes associated with the user of the type name, first name, date of birth, address, etc.
  • This organization can also be a university issuing certified accreditations consisting of student cards, which have certain attributes associated with a student of the type name, first name, student number, studies followed, etc.
  • the user may then want to use such accredited accreditations anonymously, that is to say by minimizing the information that it provides this service provider to obtain the desired service.
  • access to specific services may be restricted to the inhabitants of a city.
  • the user must then prove that he lives in the correct city, certified by the mayor, but he may not want to reveal the other attributes concerning him on his identity card, such as his name or his exact address.
  • a student may want a discount on a service offered by a third party.
  • the student must then prove that he or she has an accreditation from (for example) a university, but may not want to reveal the other attributes of his student card, such as his name or the studies he is studying. follows.
  • the trusted entity is the organization that issues accreditations.
  • the trust entity can be a town hall or a university.
  • the user may reveal one or more attributes associated with him, depending on the request of the third party acting as a service provider from whom he requires a service, in generating, like group signature techniques, proof of knowledge of undisclosed attributes and a signature on the set attributes, whether revealed or not, without disclosing either the undisclosed attributes or the signature of the certifying organization.
  • the user thus preserves his anonymity vis-à-vis the outside world.
  • Such a signature scheme consumes computing time because it requires explicitly hiding the unrevealed attributes.
  • the size of the proof therefore depends on the number of attributes initially certified by the issuing entity.
  • its practical implementation requires the use of cryptographic data of significant size, as is the case in the Idemix technology proposed by IBM.
  • blind signatures the idea is to blindly sign the attributes by the certifying organization.
  • the use of such a blind signature makes the accreditation system more efficient, however to the detriment of increased traceability of the user, since the certifying organization is involved in each access request.
  • An example of this type of technique is included in the UProve technology offered by Microsoft.
  • the invention aims to improve the situation.
  • the invention relates to a method for controlling anonymous access to a service, in which a user electronic device stores a certified set of attributes and a modification key, said set having been certified by an electronic certification device to using a sanitizable electronic signature function, said function being associated with a signature key stored in said certifying electronic device and with said modification key, the method comprises: / al / modification, by the electronic device of the set of attributes, said modification comprising the deletion of attributes other than the attributes required for anonymous access to said service,
  • This method is advantageous in particular in that it allows the electronic user device to prove to the electronic verification device that it holds attributes giving access to a given service, without having to disclose to the electronic device verification other attributes
  • the invention also relates, in particular, to a user electronic device arranged to store a modification key as well as a certified set of attributes, the stored set of attributes being certified by a certifying electronic device with the aid of a sanitizable electronic signature function, said function being associated with a signature key stored in said certifying electronic device and with said modification key, the user electronic device being arranged to modify the set of attributes by deleting attributes other than the attributes required for anonymous access to that service, and to determine, by means of the modification key, the signature of the modified set of attributes, in order to allow the subsequent verification by an electronic verification device , because the electronic signature of the modified set corresponds to a valid signature of the electronic device certifying authority.
  • This device is particularly advantageous in that it is arranged to prove to the electronic verification device that it holds attributes giving access to a given service, without having to disclose to the electronic device verification other attributes (likely to undermine to privacy).
  • the invention also relates, in particular, to an anonymous access control system to a service, comprising a user electronic device according to one embodiment of the invention, and at least one of the following two devices:
  • an electronic certifying device arranged to certify a set of attributes by means of a sanitizable electronic signature function, said function being associated with a signature key stored in the certifying electronic device as well as with a modification key, so as to enable the user electronic device, when it has previously stored the certified attribute set and the modification key, to modify the set of attributes by deleting attributes other than the attributes required for the access anonymous audit service, and determine, using the modification key, the signature of the modified set,
  • an electronic verification device arranged to receive from the user electronic device a certified set of attributes, and to check that the electronic signature of the received set corresponds to a valid signature of a certifying electronic device.
  • the invention also relates, in particular, to a computer program arranged to implement a method according to an embodiment of the invention when it is executed by a processor.
  • the invention also relates, in particular, to a non-transitory storage medium readable by computer, storing a computer program according to an embodiment of the invention.
  • FIG. 1 illustrates a method according to one embodiment
  • FIG. 2 illustrates the architecture of a user electronic device according to one embodiment
  • FIG. 3 illustrates a system according to one embodiment
  • FIG. 1 illustrates a method according to which, the axis of time t being oriented from top to bottom, after a first INIT initialization step (indicated in dashed lines since it is not part of the process in this case), the method modifies (during a MODIFY step) a set of attributes FIRST_N, LAST_N, BIRTH_D, BIRTH_P, ADDR, CITY, STATE, CSHIP by erasing the FIRST_N, LAST_N, BIRTH_P, ADDR, STATE, CSHIP attributes and retaining only the attributes BIRTH_D, CITY. The method then determines (during a DETERM step) a new signature of the set of attributes whose aforementioned attributes have been deleted.
  • a first signature was previously calculated during the INIT step, during which a certifying electronic device CERT_SRV had certified the attributes on behalf of the user electronic device ID_CARD.
  • the method can be followed by a step (shown in dashed lines because it is not part of the process) CTRL control of the validity of the signature of the attributes modified by an electronic verification device VERIF_PC.
  • FIG. 2 symbolically illustrates the architecture of a user electronic device according to one embodiment of the invention (in this case a smart card ID_CARD).
  • This card has a microcontroller, in the form of a single component (although the different elements are represented schematically as if they were discrete).
  • the microcontroller integrates a processor PROC, a random access memory RAM, and a ROM memory (which can store an operating system as well as a computer program adapted to implement a method according to an embodiment of the invention when it is executed by the processor PROC).
  • the microcontroller also integrates an EEPROM programmable memory (it could obviously be another technology, such as Flash memory), memorizing various information, including a modification key MOD_K and eight attributes FIRST_N, LAST_N, BIRTH_D, BIRTH_P, ADDR , CITY, STATE, CSHIP.
  • FIG. 3 illustrates a system according to a possible embodiment of the invention, comprising an electronic certification device (in this case a CERT_SRV server), a user electronic device (in this case a smart card ID_CARD), and an electronic verification device (in this case a personal computer VERIF_PC).
  • the server includes a Trusted Platform Module (TPM), which is a secure component, storing a SIG_K signature private key.
  • TPM Trusted Platform Module
  • the computer VERIF_PC is connected to an NFC reader allowing him to communicate with the card ID_CARD.
  • the computer is also connected to a door which it can control the opening according to its communications with the card ID_CARD.
  • One embodiment of the invention relates to a method for controlling anonymous access to a service.
  • the service can be a service of any kind.
  • This may be for example a service consisting of controlling the opening of a turnstile, an airlock, or a door, by controlling the stopping of the power supply of an electromagnet holding a door in the closed position (or also controlling the rotation of an electric motor controlling the disengagement of a bolt from the strike of a lock), thus giving access to a particular space whose access is restricted.
  • the service can more simply consist in controlling the lighting of a particular indicator (for example a green light bulb or a red light bulb depending on whether the access is authorized or not, or even the display of an explicit message in the form of text on a computer screen), allowing a human controller to decide whether to let another human, the holder of a user electronic device, pass through.
  • An electronic user device ID_CARD (such as an electronic identity card, an electronic student card, or an NFC mobile phone) stores (for example during an initialization step prior to said process, or during said process) a certified set of attributes.
  • the fact that the attributes are certified means that they are associated with one (or more) signature (s) of one (or more) authority (s). This (or these) signature is stored with the attributes, in order to be able to verify that these attributes are actually correctly certified.
  • the authority may be for example a town hall, authorized to certify said attributes.
  • Attributes may include, as a non-limiting example, a FIRST_N first name, LAST_N last name, BIRTH_D birthdate, BIRTH_P birthplace, ADDR postal address, CITY home city, state of residence STATE, and / or a CSHIP nationality / citizenship.
  • Said assembly is certified (for example during an initialization step prior to the process, or during said process) by a certifying electronic device CERT_SRV.
  • This certifying electronic device is typically a server (but can also be any type of computer or dedicated dedicated electronic hardware). It can include security elements (such as an HSM - hardware security module - for key management).
  • the certifying electronic device can be operated for example by the said authority or under its control (it is possible that the certifying electronic device is for example operated by a specialized service provider on behalf of a town hall).
  • An electronic signature function is a function implemented by an electronic device, taking as input a message (which can be represented by a series of bits) and producing, with the aid of the message and a private signature key, a signature of this message (signature may itself be represented by a sequence of bits).
  • the signature is linked to the message and to the holder of the private signature key (changing the message changes the signature, and a different signature key produces a different signature).
  • the signature can also involve additional parameters (such as a hazard that can be concatenated to the message, thus making it possible to produce two different signatures in two signatures the same message with the same private signature key).
  • a sanitizable electronic signature function is a variant of a conventional electronic signature function, according to which a message / signature pair can be modified a posteriori in a predefined manner and controlled by the entity holding the private signature key (it is ie the entity entitled to sign, ie in the general case the above-mentioned authority or its provider), but without interaction with this entity.
  • This possibility of modification is the only exception to the principle that it is mathematically very difficult (in practice impossible) to determine the signature of a message without knowing the private key signature. More precisely, the message is modified, and the signature of the modified message is recalculated according in particular to the modification made to the message and the previous signature.
  • the signature is modified (ie, recalculated) so that once modified, it is a valid signature of the new message (the modified message).
  • "Sanitization" can be public (everyone can then modify the message / signature pair retrospectively, within the limits of authorized modifications) or can only be done by one (or a group of) designated “sanitizer (s)".
  • the message can only be modified within the limits defined as being admissible by the entity holding the signature key. These limits may include not only the possible modifications (typically the permission to delete an attribute but not that of replacing it with a different valid attribute), but also the entities entitled to make these changes.
  • the control of the admissibility of a message modification is operated using a modification key generated for example under the control of the authority (but not necessarily held by it).
  • a modification key generated for example under the control of the authority (but not necessarily held by it).
  • only a holder of the change key can make changes and recalculate a legitimate signature.
  • the sanitisable signatures thus provide the means for a signatory to delegate to another entity the power to modify a signed message, so that the modified message is still considered to have been signed by the initial signer (since it is associated with a valid signature recalculated).
  • Possible constructs of sanitizable signature functions can use a standard signature scheme with the use of a hash function.
  • a preliminary step in the use of the hash function may be to divide the message to be signed into several parts (each of which may correspond to an attribute), depending on what can be modified by the electronic device or not. user, and then use a chameleon hash function on the editable parts.
  • a standard cryptographic hash function can then be applied to the result so obtained, and then a conventional electronic signature function can be used.
  • the modification key (or "sanitization trap") used by the user electronic device can then correspond to the hatch of the chameleon hash function.
  • Such hash functions are described in particular in the article "Chameleon Hashing and Signatures" by Hugo Krawczyk and Tal Rabin (October 1997), the content of which is incorporated by reference.
  • a hash function is usually devoid of predictable collisions, that is, it is not possible in practice to find two different messages on which the application of a hash function gives the same result.
  • a chameleon hash function allows, using a trapdoor (an appropriate secret key) to construct such collisions. For this, the output of the hash function is associated with a so-called 'random' value which will vary according to the hashed message (and for a given collision).
  • the user electronic device also stores a modification key in order to be able to recalculate the signature of the message once the message has been modified.
  • the user electronic device may be the sole entity holding this modification key.
  • Said sanitisable electronic signature function is associated with a signature key stored in said certifying electronic device (if it is not stored anywhere else, the non-repudiation of the signature may be improved).
  • Said function is also associated with said modification key (mentioned above). This key may only be stored in the user electronic device.
  • the method comprises:
  • said modification comprising the deletion of attributes other than the attributes (for example BIRTH_D date of birth and CITY city of residence attributes) required for anonymous access to said service, / a2 / the determination, by the user electronic device, using the modification key, the signature of the modified set, to allow the subsequent control (either in the part of the method according to the present embodiment, or in the context of another process), by an electronic verifier device VERIF_PC, because the electronic signature of the modified set corresponds to a valid signature of the certifying electronic device.
  • attributes for example BIRTH_D date of birth and CITY city of residence attributes
  • a student can thus prove, when entering a cinema, that he is over sixteen (the film he wants to see being banned at the age of sixteen) using a user electronic device such as his card. (smart) student, and he lives in the city of the cinema considered (which if any entitles him to a reduction) without disclosing his precise address, his full name and any other personal information not required to view the film and benefit from a preferential rate.
  • the determination of the signature of the set modified by the user electronic device, using the modification key is performed without it being necessary for the user electronic device to communicate with the user.
  • certifying electronic device (there may be communications between these devices, but they need not reveal any information on the attributes stored in the user device).
  • the subsequent verification by the electronic verification device of the fact that the electronic signature of the modified assembly corresponds to a valid signature of the certifying electronic device does not require the electronic verification device to communicate with the electronic device. certifier.
  • the certifying electronic device even if it is brought to communicate with the electronic verification device, acquires no information on the attributes.
  • the method prevents the town hall from recovering (for example via its electronic certifying device) information likely to identify the user, not only by the absence of communication between the certifying electronic device and the user electronic device on the one hand, and the electronic verification device on the other, but also by the protocol implemented by the method.
  • This protocol can prevent the certifying electronic device from establishing a link between an access authorization request by a user electronic device (and / or the processing of this access request by an electronic verification device) and information identifying a particular user electronic device.
  • the certifying electronic device may be involved during the access request by the user electronic device and its processing by the electronic verification device.
  • the protocol implemented can then prevent the certifying electronic device from deriving, from the information to which it is brought to access, identification information of the user.
  • the method implements a protocol preventing a link between the signature issued by the certifying electronic device and that which is determined by the user electronic device from this previous signature.
  • This method is advantageous in that it preserves anonymity (by not disclosing all the attributes but only those that are necessary), while preserving authentication (the user electronic device proves that it holds the critical attributes for access to the service).
  • This method is also advantageous in that it makes it possible to prevent the user electronic device from modifying the protected attributes other than by erasing them (thus, it can not, for example, replace one family name with another), and in that the electronic user device can erase only the authorized attributes (it may be forbidden to erase certain attributes).
  • the method also prevents a user electronic device from sharing its attributes with others. For this purpose, it can be provided that the modification key can not be extracted from the user electronic device.
  • the modification key can be stored in a file such as a file of type EF (elementary file in the sense of the aforementioned ISO standard ).
  • This EF file can be read protected, but accessible to the OS (operating system) of the smart card (or to an application such as a softmask or applet javacard).
  • the modification key can be used by the user electronic device itself (using, for example, the predefined functions that it embeds in its secure operating system), but not extracted (a command of the type READ_BINARY defined by the ISO returning an error code since the read access is forbidden).
  • a user electronic device can not therefore be fraudulently combined with others, in order to reconstruct a false identity (for example by combining the attribute FIRST_N of a first device with the attribute LAST_N of a second device and the BIRTH_D attribute of a third device).
  • the method may be implemented using a sequence of instructions constituting a computer program executed by a processor of the user electronic device. But it can also be implemented by means of a dedicated electronic circuit integrated in the user electronic device, such as an ASIC, an FPGA (or PAL, EPLD, PLD, CPLD, PLA variants, etc.) suitably configured (for example in VHDL), or dedicated dedicated electronics.
  • an access control method is implemented so that the signature of the modified set is determined without the user electronic device communicating with the certifying electronic device, in order to allow the subsequent verification by the electronic verification device without the electronic verification device communicating with the certifying electronic device, because the electronic signature of the modified set corresponds to a valid signature of the certifying electronic device.
  • the deletion of attributes implemented by the access control method comprises removing the attributes to be deleted from the set of attributes.
  • the deletion of attributes implemented by the access control method comprises the replacement of the attributes to be erased by anonymous information.
  • the method can replace the attributes to be erased by distinguished characters (without correlation with the attribute to be replaced).
  • the LAST_N surname attribute can contain the string "DUCHESNES” for example, be replaced by one of the strings "XXXXXXXX", "" (string consisting of space characters)? , " ", " ######### ", or " ????????? Which are obviously only indicative and not limiting.
  • Replacement attributes can be the same size as the original attributes (in number of bits). In this case, the attributes can have a predefined size regardless of their content.
  • a surname attribute can be 35 characters, regardless of the last name registered in this attribute (names are assumed to be 35 characters or less in length, otherwise they can be truncated to 35 characters, or any other size considered appropriate for the attribute considered).
  • the surname can then be registered either at the beginning, middle, end, or in any position of the field of 35 characters reserved for the last name, the unused characters of the field being able to be defined in a conventional way (for example they may be space characters, such as the ASCII 32 character code, or 0x20).
  • the sanitizable electronic signature function of the access control method is a caviardable signature function, or an electronic signature function coupled to a chameleon hashing function, or an electronic signature function coupled to a blackening function.
  • Caviardable signature functions are electronic signature functions that hide certain parts of a signed message while keeping the signature valid. They can rely on the construction of certificates (kinds of digital identity cards) with properties of redaction (typographic term denoting the removal of parts of a text). For example, a student may hide certain attributes of his digital identity card without making it unusable.
  • the caviardable signature functions can be a simple version of the sanitisables signatures.
  • the caviardable signature functions can be based in particular on a chameleon signature scheme.
  • the caviardable signature functions implemented in the process may blacken the attributes to be hidden (all attributes except the attributes required for service access) by replacing them with distinguished characters, but they may also be so-called signature functions deletable, where we remove (remove) the attributes to hide, without replacing them with anything (even distinguished characters). They only allow an entity with the right trap, to blacken or delete certain well-defined parts of a message, so that it is not practically possible to determine these parts from the blackened (or deleted) parts. is clear that one can not determine information from nothing). Blackening sensitive information means replacing this information (such as an attribute that is not required to disclose) with uncorrelated information that does not disclose sensitive information (eg, distinguished characters, such as characters " ############# ").
  • the user electronic device By having a set of attributes signed by an electronic certifying device using a removable signature (possibly deletable), and by giving the hatch (the modification key) to the user electronic device, the user electronic device is therefore in able to blacken (or delete, according to the technique used) the attributes that he does not wish to reveal, then to modify the signature so that it seems to have been produced by the certifying electronic device.
  • the user electronic device is thus, during a request for access to a service, anonymously vis-à-vis the outside (whether vis-à-vis the electronic device verification, electronic certifying device, or any other entity) and discloses to the electronic verification device only the requested attributes.
  • the user electronic device is not able to modify the attributes initially signed by the certifying electronic device other than by deleting them or by replacing them with "neutral" information (not corresponding to any legitimate attribute of the same type, as the name of another city for an attribute indicating a city) and therefore can not cheat by masquerading as an electronic user device holding different attributes.
  • the attributes for example the attributes BIRTH_D and CITY
  • the method comprises a determination of said required attributes according to said service.
  • the same electronic user device may allow its human holder to access a cinema but also to access a municipal swimming pool. Cinema access with a reduced rate may be subject to the presentation of an authorized CITY attribute.
  • the electronic device can determine that only the attributes CITY and BIRTH_D are likely to be required.
  • the user electronic device can automatically erase all other attributes. It can alternatively leave the user of the user electronic device the opportunity to delete the attributes of his choice (the attributes may correspond to attributes of the human user himself). It may be forbidden for the human user to erase certain attributes, for example the attribute BIRTH_D.
  • the non-presentation (by deletion) of the attribute CITY entails for example simply the absence of reduction, but it is not possible not to present its age (this is obviously only an example , it is possible that the age is also erasable).
  • the attributes may be different from those required for access to the cinema. For example, there may be an attribute indicating the date of the last medical fitness certificate duly presented to an authorized authority, and it may be provided that only an authenticated holder of an attribute indicating a date of less than one year has the right to enter the pool.
  • the entity that accesses the service using the user electronic device may be a human user of the user electronic device.
  • a human user when entering a cinema, a human user can present his ID card to an NFC reader to validate that he has the right to see a movie based on the attributes of the ID card.
  • the service may also be provided to the user electronic device.
  • the human user can then access the service via the electronic device.
  • the user electronic device may be a mobile phone, and the service may be a video-on-demand service, in which case the video is sent to the mobile phone (the service is therefore provided to the user electronic device), and the human user can view the video on his mobile phone.
  • the human user may have to leave his electronic user device (identity card, student card, etc.) at the entrance, and only pick it up at the exit (shooting club , a library reserved for researchers and giving access to invaluable works, visiting a site classified confidential defense, etc.).
  • the user electronic device may also be a mobile phone storing the personal data required for access (the attributes), the access may be authorized by the mobile phone but its human user may be obliged to leave the mobile phone at the entrance or turn it off. This type of situation is also conceivable for electronic devices users other than mobile phones.
  • the electronic user device may contain personal information printed (for example in the case of an identity card).
  • the user electronic device may contain printed information relating to characteristics different from the features that are the subject of the stored attributes.
  • the photo, initials, and department in which a student researcher works may be printed on his student card, but his full name, home address, and date of birth may only be available as attributes recorded in the chip of his student card. This is advantageous especially in the case where the user electronic device must be left at the entrance.
  • the user electronic device may comprise the same information in the form of stored attributes and printed data, but may be delivered to a closed setpoint in exchange for the unique key of a lock of the setpoint, or, in the case of a card, to be swallowed by a card reader (in the manner of a ticket distributor), stored inside, and returned on presentation of an identifier and a PIN code of the card (without no one other than the holder has the opportunity to see what is printed on the card), after delivery of the service to the human user.
  • the access control method comprises certifying, by the certifying electronic device, the set of attributes using the sanitisable electronic signature function.
  • the access control method comprises the control, by the electronic verification device, of the fact that the electronic signature of the modified set corresponds to a valid signature of the certifying electronic device.
  • a user electronic device ID_CARD is arranged to store a modification key MOD_K and a certified set of attributes FIRST_N, LAST_N, BIRTH_D, BIRTH_P, ADDR, CITY, STATE, CSHIP.
  • the user electronic device can be a smart card, which is advantageous for security. It can be any smart card, in particular a contact card (for example the ISO 7816-2 standard), a contactless card (for example a card MiFare standard, ISO 14443 standard , or including any NFC interface), a contact and contactless contact card with a chip common to both interfaces or with a separate chip for each contact and contactless interface, etc.
  • the card can be in ID-1 format of ISO-7810, in ID-000 format of this same standard (“plug-in" format), in microSIM format, or in any other suitable format (it can be act on a paper identity document in the format of a conventional passport, etc.).
  • the card may include a credit card chip, SIM card (the acronym SIM, the English Subscriber Identity Module, refers generically all variants CSIM, USIM, UICC etc.), PKI card, card access, health card, transport card, identity card, passport, tachograph, etc.
  • SIM card the acronym SIM, the English Subscriber Identity Module, refers generically all variants CSIM, USIM, UICC etc.
  • PKI card PKI card
  • card access health card
  • transport card identity card
  • passport passport
  • tachograph etc.
  • the user electronic device may be a SIM card equipped with an electronic circuit capable of managing NFC type wireless communications.
  • the SIM card may include a SWP (Single Wire Protocol) compliant contact allowing the SIM to connect to an antenna built into the phone. portable and operate independently. In other words, the card can work regardless of whether the notebook is on or off and the mobile phone's battery is charged or empty.
  • SWP Single Wire Protocol
  • the card can in fact be powered by the electromagnetic field generated for this purpose by the NFC reader with which it enters into communication (an NFC reader integrated with the electronic verification device, or communicating with it) via the NFC antenna of the mobile phone.
  • This makes it possible to set up a better controlled and more secure environment than that of the mobile phone, which is often much more complex and open (allowing the loading of third-party applications, and possibly viruses).
  • the electronic user device may also be a memory card with a processor (secureMMC type, etc.), a USB key, etc.
  • the user electronic device may also be any computer.
  • the set of attributes stored in the user electronic device is certified by a certifying electronic device CERT_SRV using a sanitizable electronic signature function. Said function is associated with a signature key SIG_K stored in said certifying electronic device as well as said modification key MOD_K.
  • the user electronic device is arranged to modify the set of attributes by deleting attributes other than the attributes BIRTH_D and CITY required for anonymous access to said service, and to determine, using the modification key, the signature of the modified attribute set.
  • an electronic verifier VERIF_PC which can be a PC type computer, a server, an NFC reader comprising a circuit for communicating with the user electronic device, etc.
  • VERIF_PC which can be a PC type computer, a server, an NFC reader comprising a circuit for communicating with the user electronic device, etc.
  • a user electronic device is arranged to determine the signature of the modified set of attributes without communicating with the certifying electronic device. This allows the subsequent control, by the electronic verification device, without this electronic verification device also communicating with the certifying electronic device, because the electronic signature of the modified set corresponds to a valid signature of the certifying electronic device.
  • the certifying electronic device being at no time involved in the access request by the user electronic device or the processing of this request by the electronic verification device, this certifying electronic device can not physically collect any information on the user electronic device ( and on its human holder) on the occasion of this transaction (and whether or not the transaction results in an approval of access).
  • a user electronic device is arranged to delete attributes other than the attributes required for anonymous access to said service by removing said attributes to be deleted from the set of attributes.
  • a user electronic device is arranged to erase attributes other than the attributes required for anonymous access to said service by replacing said attributes to be erased by anonymous information.
  • the sanitizable electronic signature function of a user electronic device is of one of the following types: a caviardable signature function, or a conventional electronic signature function coupled to a chameleon hash function, or a conventional electronic signature function coupled to a blackening function.
  • the attributes (for example BIRTH_D and CITY) required for anonymous access to the service depend on said service, the user electronic device being arranged to determine said required attributes according to said service.
  • an anonymous service access control system comprises a user electronic device according to one embodiment, and at least one of the following two devices:
  • a certifying electronic device CERT_SRV arranged to certify a set of attributes FIRST_N, LAST_N, BIRTH_D, BIRTH_P, ADDR, CITY, STATE and CSHIP by means of a sanitizable electronic signature function, said function being associated with a key of signature stored in the certifying electronic device and a modification key, so as to allow the user electronic device, when it has previously stored the set of certified attributes and the modification key, to modify the set of attributes by deleting attributes other than the BIRTH_D and CITY attributes required for anonymous access to said service, and determining, with the aid of the modification key, the signature of the modified set,
  • an electronic verifier device VERIF_PC arranged to receive from the user electronic device a certified set of attributes BIRTH_D, CITY, and to check that the electronic signature of the received set corresponds to a valid signature of a certifying electronic device CERT_SRV.
  • the user electronic device can be arranged to communicate with the certifying electronic device via a wired or wireless network (for example Ethernet, WiFi, ATM, ADSL, satellite, Wimax, 1G, 2G, 3G, 4G etc.) possibly via a host (for example a personal computer or a mobile phone to which the user electronic device is connected).
  • the electronic verification device may also be arranged to communicate with the certifying electronic device via a wired or wireless network (for example Ethernet, Wi-Fi, ATM, ADSL, satellite, Wimax, 1G, 2G, 3G, 4G etc.).
  • the user electronic device and the electronic verification device may be arranged to communicate neither with the certifying electronic device.
  • the user electronic device and the electronic tester device can be arranged to communicate with each other using wired or wireless protocols which can be short range protocols (ZigBee, Bluetooth, infrared such as irDA, USB connection, FireWire connection - IEEE 1394, Sata or eSata connection, PLC connection, Wireless USB connection, proprietary connection, ISO 7816, ISO 14443A or ISO 14443B, Wi-Fi, etc.).
  • short range protocols ZigBee, Bluetooth, infrared such as irDA, USB connection, FireWire connection - IEEE 1394, Sata or eSata connection, PLC connection, Wireless USB connection, proprietary connection, ISO 7816, ISO 14443A or ISO 14443B, Wi-Fi, etc.
  • the certifying electronic device may comprise redundancy elements, for example hard disks or memories protected by a well known RAID technique (redundant array of independent disks), thus protecting against the loss of the signature key without imposing any storing this key outside the certifying electronic device.
  • redundancy elements for example hard disks or memories protected by a well known RAID technique (redundant array of independent disks), thus protecting against the loss of the signature key without imposing any storing this key outside the certifying electronic device.
  • a computer program is arranged to implement a method according to an embodiment when executed by a processor.
  • the processor may be a processor of the user electronic device, or a processor of a security module inserted in such a device (for example a SIM card processor inserted in a mobile phone).
  • the computer program can be written in C language, Java, C ++, C #, Basic (and its many variants), assembler, or any other appropriate language.
  • the computer program may include instructions adapted to take advantage of a dedicated hardware support of the processor, such as a cryptoprocessor to speed up certain calculations (such as modular exponentiations) that may otherwise be slower to implement. based solely on a standard processor instruction set.
  • a computer-readable non-transitory storage medium stores a program according to a possible embodiment.
  • the storage medium may be for example a smart card, a USB key, a microcontroller with non-volatile memory (EEPROM, Flash, ROM, etc.), a memory chip, a memory card, a magnetic storage medium (hard disk, magnetic tape, floppy disk, etc.), or any other form of suitable storage.
  • An anonymous accreditation system Participants in an anonymous accreditation system are organizations (with certifying electronic devices), users (with electronic certifying devices), and verifiers (with electronic verification devices). Organizations issue accreditations (eg, certified attributes) to users, who can use them anonymously with auditors (eg service providers).
  • An anonymous accreditation system can implement the following functions.
  • Setup function is to generate system parameters. It takes as input a security parameter (which can correspond to the size of the cryptographic elements to be manipulated) and returns param parameters (group elements and scalars that are public).
  • the OrgKeyGen and UserKeyGen functions generate (secret and / or public) keys for, respectively, organizations and users.
  • the Obtain function performed by the user, takes as input a secret key skU and a public key organization pkO.
  • the Issue function carried out by the organization, takes as input a secret organization key skO, a user public data pkU and a list of attributes (name, date of birth, study, etc.) that it wishes to certify to the user
  • the user U has obtained a certificate C (or an error message was generated).
  • the double arrow symbolizes the interactions between the different programs that run and the arrows indicate the outputs of the functions.
  • AC Show AC: Verify. These two functions form a protocol executed between a user wishing to justify the possession of an accreditation and a verifier wishing to verify this possession.
  • the Show function performed by the user, takes as input a secret key skU, a public key pkO, a list of messages and an accreditation C.
  • the Verify function executed by
  • the verifier takes as input a public key pkO and a list M of messages such that
  • the Verify function returns a bit indicating whether he accepts the proof of possession of the user.
  • the verification protocol is public: it does not require a secret key to be executed.
  • a message m is, generically, a bit string of length (that is, a sequence of bits 0 or 1, of arbitrary length as indicated by the star *).
  • N is the number of blocks and a concatenation symbol.
  • the fixed part a message according to a set of admissible portions ADM is given by the function or
  • Mod modification instructions given an assignment of allowable (ie, modifiable) portions (or blocks) ADM for a message are given by a list of pairs of indices and messages (that is, the modified block m ' j has the same size, in number of bits, as the original block), for all
  • the notation indicates that MOD modification instructions are compatible with ADM eligible portions. That is, these instructions do not require modifying a block that has not been designated as editable.
  • ADM be eligible portions and two messages with change instructions. If the messages are identical once sanitization has been applied, then
  • SAN In a sanitisable signature scheme, noted SAN, two types of participants are present: signers and sanitizers.
  • a sanitizable signature scheme is given by the following five functions.
  • the Setup function generates the system settings. It takes as input a security parameter ⁇ (which corresponds to the size of the cryptographic elements to be manipulated) and returns param parameters (elements of a group and scalars that are public).
  • ⁇ which corresponds to the size of the cryptographic elements to be manipulated
  • param parameters (elements of a group and scalars that are public).
  • SAN SigKeyGen
  • SAN SanKeyGen
  • the SigKeyGen and SanKeyGen functions generate keys for, respectively, signers and sanitizers.
  • the signature function Sign takes as input a secret key a sanitizer designated by
  • the index to which he wishes to delegate the right to modify the message a message m and ADM eligible portions. It generates a signature (or an error message using the same notation as for the function of blackening / deletion but this is a different concept).
  • the sanitize sanitize function takes as input a secret key of sanitizer the key public of the signer the message m, the signature and changes to MOD instructions. She
  • Verify function takes as input the public key of the signer the message m
  • the verification procedure is public: it does not require a secret key to be executed.
  • sanitisables signatures There are different versions of sanitisables signatures. The functional and security properties of these different versions vary by version. In the context of the embodiments described below, the method relies on sanitisable signatures fulfilling the following conditions. Other properties could be added, but are not essential. These are conditions necessary to obtain the desired properties for anonymous accreditations in the context of these embodiments (of course, other less secure embodiments are possible).
  • Verification of a signature must not require the public key of the sanitizer who has the right to modify the message / signature pair that one has. This allows us to obtain the anonymity of the sanitizer (and therefore the user in our system of accreditations). Indeed, even if the public key was not linked to a formally identified individual, the mere fact that it exists would at least make it possible to follow the transactions of the user associated with this public key, and as soon as one of the transactions reveals its identity, it would be possible to associate all the corresponding transactions with it.
  • the sanitizer key is required, but it is hidden at the time of verification.
  • the method relies on a proof of zero disclosure of knowledge (so-called "zero-knowledge”) to hide the key of the sanitizer, while proving that the signature obtained is valid.
  • the user / sanitizer must not be able to replace one of his attributes with something that suits him (for example, to replace his real city of residence with the one he wants to take advantage of).
  • the sanitizer must not be able to replace an eligible part of a message signed by what he wants. It is therefore necessary to have a system which limits the modifications that the sanitizer can make.
  • the replay of a sanitized signature must be infeasible. This phase must contain a hazard controlled by both the sanitizer and the verifier.
  • An anonymous AC credential system is based on a SAN sanitable signature scheme respecting the PIA or PIB properties, as well as P2 to P4, set out above.
  • the AC Setup procedure for generating anonymous credential system settings is the SAN: Setup procedure for generating the sanitisable signature scheme parameters.
  • the procedure AC: UserKeyGen of generation of the keys of the users of the anonymous system of accreditation is the SAN procedure: SanKeyGen of generation of the keys of the sanitizers of the sanitisable signature scheme.
  • the procedure AC: OrgKeyGen of generating the keys of the organizations of the anonymous system of accreditation is the procedure SAN: SigKeyGen of generation of the keys of the signers of the sanitisable signature scheme.
  • O separates m into N blocks of respective lengths and specifies a subset of indices at his convenience. A specific field of index n is chosen. The organization O then generates a signature using the public key pku
  • the user U records as an accreditation of O on the message m.
  • the document to be accredited may correspond to a concatenation of the names (or identifiers) of the fields (for example LAST_N, ADDR, etc.) and to the value of each of these fields in the case in question (for example "Lescuyer”, "Caen”, etc.). Eligible parties can match field values, and exclude field identifiers (in this case, the user must not be able to modify LAST_N but must be able to modify "Lescuyer", at least he must be able to modify it in an authorized way ).
  • the public key of the user who obtains the accreditation corresponds to his public sanitizer key.
  • the AC Show protocol
  • Verify the use of an accreditation by a user U to a verifier V can be performed in the following manner. Suppose that a verifier V wishes to verify that a user U has an accreditation certifying the possession of a set of attributes M Suppose the user U has an accreditation on a document
  • the verifier sends a random value r to the user U.
  • This value r can be for example the concatenation of data specific to the verification and the current time.
  • the user U sanitizes the document according to the following modification instructions
  • the user sends to the verifier.
  • the verifier verifies that the signature is a valid message signature thanks to the public key of the organization O. It returns 1 if it is the case and 0 otherwise.
  • a document can be defined as any string of bits.
  • the message space is therefore However, all the documents to be signed include a reserved field of fixed length
  • the message blocks to be blackened are blackened in a unique way.
  • a block of length is always replaced by a block of the same size.
  • the blackening of a block may for example consist of a replacement of this block by a sequence of bits 0 of the same length as this block.
  • This embodiment is placed in the context of a symmetric bilinear environment to perform the calculations.
  • the signer generates his keys by implementing the following actions:
  • the sanitizer registers with a signatory, implementing the following actions:
  • Each of the parties (the signer and the sanitizer) then records this data as a certificate of membership in the system
  • the protocol for obtaining an accreditation between a user, already registered, and an organization is implemented as follows.
  • the protocol gathers user data into one document of length t (in bits).
  • the organization separates the document blocks of respective lengths and specifies a subset of indices designating the portions of messages that the user can hide.
  • the protocol chooses a specific field (reserved field), index and length
  • the protocol defines, which means that the reserved field can be modified at will by the user while the other modifiable blocks can only be blackened.
  • the secret key Sanitizer i is represented by his certificate
  • the signer implements the following actions.
  • the organization After performing these calculations (for example with the certifying electronic device), the organization gives the user. This one records as accreditation on the message m.
  • accreditation may have been issued on a message by the organization identified by
  • the user has a certificate
  • the signature is of the form:
  • the user wants to hide a subset of attributes of the document is the subset of indexes of message blocks that the user has the right to blacken.
  • the verifier sends the user a random value (for which a reserved field is provided).
  • a random value for which a reserved field is provided.
  • the user then sends to the verifier.
  • the method embodiments can be transposed to the devices, and vice versa.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Storage Device Security (AREA)

Abstract

La demande se rapporte notamment à un procédé de contrôle d'accès anonyme à un service. Un dispositif électronique utilisateur (ID_CARD) stocke un ensemble certifié d'attributs (FIRST_N, LAST_N, BIRTH_D, BIRTH_P, ADDR, CITY, STATE, CSHIP) et une clé de modification (MOD_K). Cet ensemble est certifié par un dispositif électronique certificateur (CERT_SRV) à l'aide d'une fonction de signature électronique sanitisable. Cette fonction est associée à une clé de signature (SIG_K) stockée dans le dispositif électronique certificateur ainsi qu'à ladite clé de modification (MOD_K). Le procédé comprend la modification, par le dispositif électronique utilisateur, de l'ensemble d'attributs, ladite modification comprenant l'effacement d'attributs autres que les attributs (BIRTH_D, CITY) requis pour l'accès anonyme audit service. Le procédé comprend également la détermination, par le dispositif électronique utilisateur, à l'aide de la clé de modification, de la signature de l'ensemble modifié, afin de permettre le contrôle ultérieur, par un dispositif électronique vérifieur (VERIF_PC), du fait que la signature électronique de l'ensemble modifié correspond à une signature valide du dispositif électronique certificateur.

Description

Accréditations Anonymes
L'invention concerne le domaine des systèmes d'accréditation anonyme pour l'accès à des services.
Dans un système d'accréditation habituel, une organisation de confiance émet, pour certains utilisateurs, des accréditations certifiées portant sur un ou plusieurs attributs de cet utilisateur.
Une telle organisation peut être, par exemple, une mairie émettant des accréditations certifiées consistant en des cartes d'identité, lesquelles présentent un certain nombre d'attributs associés à l'utilisateur du type nom, prénom, date de naissance, adresse, etc. Cette organisation peut également être une université émettant des accréditations certifiées consistant en des cartes d'étudiant, lesquelles présentent certains attributs associés à un étudiant du type nom, prénom, numéro d'étudiant, études suivies, etc.
Lorsqu'il souhaite accéder à un service offert par un organisme tiers agissant en tant que fournisseur de services, l'utilisateur peut alors vouloir utiliser de telles accréditations certifiées de façon anonyme, c'est-à-dire en minimisant l'information qu'il fournit à ce fournisseur de service afin d'en obtenir le service désiré.
Par exemple, l'accès à certains services spécifiques peut être restreint aux habitants d'une ville. Dans un tel cas, l'utilisateur doit alors prouver qu'il habite bien la bonne ville, de façon certifiée par la mairie, mais il peut ne pas vouloir révéler les autres attributs le concernant sur sa carte d'identité, tels que son nom ou son adresse exacte.
De façon similaire, un étudiant peut vouloir bénéficier d'une réduction sur un service offert par un organisme tiers. L'étudiant doit alors prouver qu'il possède une accréditation provenant (par exemple) d'une université, mais peut ne pas vouloir révéler les autres attributs le concernant sur sa carte d'étudiant, tels que son nom ou les études qu'il suit.
Pour répondre à ce besoin d'anonymat, il est possible d'envisager des systèmes d'accréditation utilisant des techniques cryptographiques proches des signatures de groupe ou des signatures aveugles.
Dans le cas des signatures de groupe, l'organisation certificatrice signe, lors de la phase de création de l'accréditation, l'ensemble des attributs associés à l'utilisateur en ne produisant qu'une seule signature. Cette signature doit être telle que l'organisation certificatrice elle-même ne doit pas être capable d'utiliser cette accréditation afin de se faire passer pour l'utilisateur, ce qui est par exemple possible en utilisant des techniques liées aux schémas de signature de groupe. L'entité de confiance est l'organisation qui délivre des accréditations. L'entité de confiance peut être notamment une mairie, ou encore une université.
Une fois l'utilisateur en possession d'une telle accréditation, il peut révéler un ou plusieurs attributs qui lui sont associés, en fonction de la demande de l'organisme tiers agissant en tant que fournisseur de services auprès duquel il requiert un service, en générant, à l'instar des techniques de signature de groupe, une preuve de connaissance des attributs non révélés et une signature sur l'ensemble des attributs, révélés ou non, sans divulguer ni les attributs non révélés ni la signature de l'organisation certificatrice. L'utilisateur préserve de ce fait son anonymat vis-à-vis du monde extérieur.
Dans ce cas de figure, il est connu d'utiliser un schéma de signature permettant de signer plusieurs messages/attributs en une seule signature et où le possesseur de la signature est capable de faire une preuve de connaissance de la signature et des messages signés, sans révéler ni la signature, ni l'ensemble de ces messages/attributs qu'il souhaite cacher, tout en gardant la possibilité de donner en clair le ou les attributs qui lui sont demandés par l'organisme tiers.
Un tel schéma de signature est consommateur en temps de calcul puisqu'il nécessite de cacher explicitement les attributs non révélés. La taille de la preuve dépend donc du nombre d'attributs initialement certifiés par l'entité émettrice. Par ailleurs, sa mise en œuvre pratique nécessite l'utilisation de données cryptographiques de taille importante, comme cela est le cas dans la technologie Idemix proposée par IBM.
Dans le cas des signatures aveugles, l'idée consiste à faire signer de façon aveugle les attributs par l'organisation certificatrice. L'utilisation d'une telle signature aveugle rend le système d'accréditation plus efficace, au détriment cependant d'une traçabilité accrue de l'utilisateur, puisque l'organisation certificatrice est impliquée lors de chaque demande d'accès. Un exemple de ce type de technique est repris dans la technologie UProve proposée par Microsoft.
L'invention vise à améliorer la situation.
L'invention se rapporte notamment à un procédé de contrôle d'accès anonyme à un service, dans lequel, un dispositif électronique utilisateur stockant un ensemble certifié d'attributs et une clé de modification, ledit ensemble ayant été certifié par un dispositif électronique certificateur à l'aide d'une fonction de signature électronique sanitisable, ladite fonction étant associée à une clé de signature stockée dans ledit dispositif électronique certificateur ainsi qu'à ladite clé de modification, le procédé comprend: /al/ la modification, par le dispositif électronique utilisateur, de l'ensemble d'attributs, ladite modification comprenant l'effacement d'attributs autres que les attributs requis pour l'accès anonyme audit service,
/a2/ la détermination, par le dispositif électronique utilisateur, à l'aide de la clé de modification, de la signature de l'ensemble modifié, afin de permettre le contrôle ultérieur, par un dispositif électronique vérifieur, du fait que la signature électronique de l'ensemble modifié correspond à une signature valide du dispositif électronique certificateur.
Ce procédé est avantageux notamment en ce qu'il permet au dispositif électronique utilisateur de prouver au dispositif électronique vérifieur qu'il détient des attributs donnant accès à un service donné, sans pour autant avoir besoin de divulguer au dispositif électronique vérifieur des attributs autres
(susceptibles de porter atteinte à la vie privée). L'invention se rapporte également, notamment, à un dispositif électronique utilisateur agencé pour stocker une clé de modification ainsi qu'un ensemble certifié d'attributs, l'ensemble d'attributs stocké étant certifié par un dispositif électronique certificateur à l'aide d'une fonction de signature électronique sanitisable, ladite fonction étant associée à une clé de signature stockée dans ledit dispositif électronique certificateur ainsi qu'à ladite clé de modification, le dispositif électronique utilisateur étant agencé pour modifier l'ensemble d'attributs en effaçant des attributs autres que les attributs requis pour l'accès anonyme audit service, et pour déterminer, à l'aide de la clé de modification, la signature de l'ensemble d'attributs modifié, afin de permettre le contrôle ultérieur, par un dispositif électronique vérifieur, du fait que la signature électronique de l'ensemble modifié correspond à une signature valide du dispositif électronique certificateur.
Ce dispositif est avantageux notamment en ce qu'il est agencé pour prouver au dispositif électronique vérifieur qu'il détient des attributs donnant accès à un service donné, sans pour autant avoir besoin de divulguer au dispositif électronique vérifieur des attributs autres (susceptibles de porter atteinte à la vie privée).
L'invention se rapporte également, notamment, à un système de contrôle d'accès anonyme à un service, comprenant un dispositif électronique utilisateur selon un mode de réalisation de l'invention, et au moins l'un des deux dispositifs suivants:
- un dispositif électronique certificateur agencé pour certifier un ensemble d'attributs à l'aide d'une fonction de signature électronique sanitisable, ladite fonction étant associée à une clé de signature stockée dans le dispositif électronique certificateur ainsi qu' à une clé de modification, de manière à permettre au dispositif électronique utilisateur, lorsqu'il a préalablement stocké l'ensemble d'attributs certifié ainsi que la clé de modification, de modifier l'ensemble d'attributs en effaçant des attributs autres que les attributs requis pour l'accès anonyme audit service, et de déterminer, à l'aide de la clé de modification, la signature de l'ensemble modifié,
- un dispositif électronique vérifieur agencé pour recevoir du dispositif électronique utilisateur un ensemble certifié d'attributs, et pour contrôler que la signature électronique de l'ensemble reçu correspond à une signature valide d'un dispositif électronique certificateur. L'invention se rapporte également, notamment, à un programme d'ordinateur agencé pour mettre en œuvre un procédé selon un mode de réalisation de l'invention lorsqu'il est exécuté par un processeur.
L'invention se rapporte également, notamment, à un support de stockage non transitoire lisible par ordinateur, stockant un programme d'ordinateur selon un mode de réalisation de l'invention.
D'autres aspects, buts et avantages de l'invention apparaîtront à la lecture de la description d'un de ses modes de réalisation. L'invention sera également mieux comprise à l'aide des dessins, sur lesquels:
- la figure 1 illustre un procédé selon un mode de réalisation ;
- la figure 2 illustre l'architecture d'un dispositif électronique utilisateur selon un mode de réalisation ;
- la figure 3 illustre un système selon un mode de réalisation ;
La figure 1 illustre un procédé selon lequel, l'axe du temps t étant orienté du haut vers le bas, après une première étape d'initialisation INIT (indiquée en pointillés car elle ne fait en l'occurrence pas partie du procédé), le procédé modifie (lors d'une étape MODIF) un ensemble d'attributs FIRST_N, LAST_N, BIRTH_D, BIRTH_P, ADDR, CITY, STATE, CSHIP en effaçant les attributs FIRST_N, LAST_N, BIRTH_P, ADDR, STATE, CSHIP et en ne conservant que les attributs BIRTH_D, CITY. Le procédé détermine alors (durant une étape DETERM) une nouvelle signature de l'ensemble d'attributs dont on a effacé les attributs précités. Une première signature avait été préalablement calculée durant l'étape INIT, pendant laquelle un dispositif électronique certificateur CERT_SRV avait certifié les attributs pour le compte du dispositif électronique utilisateur ID_CARD. Le procédé peut être suivi d'une étape (indiquée en pointillés car elle ne fait en l'occurrence pas partie du procédé) de contrôle CTRL de la validité de la signature des attributs modifiés par un dispositif électronique vérifieur VERIF_PC.
La figure 2 illustre de façon symbolique l'architecture d'un dispositif électronique utilisateur selon un mode de réalisation de l'invention (en l'occurrence une carte à puce ID_CARD). Cette carte comporte un microcontrôleur, sous forme d'un seul composant (bien que les différents éléments soient représentés schématiquement comme s'ils étaient discrets). Le microcontrôleur intègre un processeur PROC, une mémoire vive RAM, et une mémoire morte ROM (pouvant mémoriser un système d'exploitation ainsi qu'un programme d'ordinateur adapté pour mettre en œuvre un procédé selon un mode de réalisation de l'invention lorsqu'il est exécuté par le processeur PROC). Le microcontrôleur intègre également une mémoire programmable EEPROM (il pourrait évidemment s'agir d'une autre technologie, telle que la mémoire Flash), mémorisant différentes informations, dont une clé de modification MOD_K et huit attributs FIRST_N, LAST_N, BIRTH_D, BIRTH_P, ADDR, CITY, STATE, CSHIP.
La figure 3 illustre un système selon un mode de réalisation possible de l'invention, comprenant un dispositif électronique de certification (en l'occurrence un serveur CERT_SRV), un dispositif électronique utilisateur (en l'occurrence une carte à puce ID_CARD), et un dispositif électronique vérifieur (en l'occurrence un ordinateur personnel VERIF_PC). Le serveur comprend un TPM (Trusted Platform Module), qui est un composant sécurisé, stockant une clé privée de signature SIG_K. L'ordinateur VERIF_PC est connecté à un lecteur NFC lui permettant de communiquer avec la carte ID_CARD. L'ordinateur est également connecté à une porte dont il est en mesure de commander l'ouverture en fonction de ses communications avec la carte ID_CARD. Un mode de réalisation de l'invention se rapporte à un procédé de contrôle d'accès anonyme à un service. Le service peut être un service de toute nature. Il peut s'agir par exemple d'un service consistant à commander l'ouverture d'un tourniquet, d'un sas, ou encore d'une porte, en commandant l'arrêt de l'alimentation électrique d'un électro-aimant retenant une porte en position fermée (ou encore commandant la rotation d'un moteur électrique contrôlant le désengagement d'un pêne de la gâche d'une serrure), donnant ainsi accès à un espace particulier dont l'accès est restreint. Le service peut plus simplement consister à commander l'allumage d'un indicateur particulier (par exemple une ampoule verte ou une ampoule rouge selon que l'accès est ou non autorisé, ou même l'affichage d'un message explicite sous forme de texte sur un écran d'ordinateur), permettant à un contrôleur humain de décider de laisser ou de ne pas laisser passer un autre humain, détenteur d'un dispositif électronique utilisateur.
Un dispositif électronique utilisateur ID_CARD (tel qu'une carte d'identité électronique, une carte d'étudiant électronique, ou encore un téléphone portable NFC) stocke (par exemple lors d'une étape d'initialisation préalable audit procédé, ou encore durant ledit procédé) un ensemble certifié d'attributs.
Le fait que les attributs sont certifiés signifie qu'ils sont associés à une (ou plusieurs) signature(s) d'une (ou plusieurs) autorité(s). Cette (ou ces) signature est stockée avec les attributs, afin de pouvoir vérifier que ces attributs sont effectivement correctement certifiés. L'autorité peut être par exemple une mairie, habilitée à certifier lesdits attributs.
Les attributs peuvent comprendre, à titre d'exemple non limitatif, un prénom FIRST_N, un nom de famille LAST_N, une date de naissance BIRTH_D, un lieu de naissance BIRTH_P, une adresse postale ADDR, une ville de résidence CITY, un Etat de résidence STATE, et/ou encore une nationalité/citoyenneté CSHIP.
Ledit ensemble est certifié (par exemple lors d'une étape d'initialisation préalable au procédé, ou encore pendant ledit procédé) par un dispositif électronique certificateur CERT_SRV. Ce dispositif électronique certificateur est typiquement un serveur (mais peut également être tout type d'ordinateur ou de matériel électronique dédié approprié). Il peut comprendre des éléments de sécurité (tels qu'un HSM - hardware security module - pour la gestion de clés). Le dispositif électronique certificateur peut être opéré par exemple par la dite autorité ou encore sous son contrôle (il est possible que le dispositif électronique certificateur soit par exemple opéré par un prestataire de service spécialisé pour le compte d'une mairie).
L'ensemble est certifié à l'aide d'une fonction de signature électronique sanitisable. Une fonction de signature électronique est une fonction mise en œuvre par un dispositif électronique, prenant en entrée un message (pouvant être représenté par une suite de bits) et produisant, à l'aide du message et d'une clé privée de signature, une signature de ce message (signature pouvant elle-même être représentée par une suite de bit). La signature est liée au message et au détenteur de la clé privée de signature (changer le message change la signature, et une clé de signature différente produit une signature différente). La signature peut également faire intervenir des paramètres additionnels (tels qu'un aléa pouvant être concaténé au message, permettant ainsi de produire deux signatures différentes lors de deux signatures d'un même message avec la même clé privée de signature). Il est mathématiquement très difficile (en pratique impossible) de déterminer la signature sans la clé privée de signature. Une fonction de signature électronique sanitisable est une variante d'une fonction de signature électronique conventionnelle, selon laquelle on peut modifier a posteriori un couple message/signature de manière prédéfinie et contrôlée par l'entité détentrice de la clé privée de signature (c'est-à-dire l'entité habilitée à signer, à savoir dans le cas général l'autorité précitée ou son prestataire), mais sans interaction avec cette entité. Cette possibilité de modification constitue la seule exception au principe selon lequel il est mathématiquement très difficile (en pratique impossible) de déterminer la signature d'un message sans connaître la clé privée de signature. Plus précisément, le message est modifié, et la signature du message modifié est recalculée en fonction notamment de la modification apportée au message et de la précédente signature. La signature est modifiée (c'est-à-dire recalculée) de sorte à ce qu'une fois modifiée, elle constitue une signature valide du nouveau message (le message modifié). La « sanitisation » peut être publique (tout le monde pouvant alors modifier le couple message/signature a posteriori, dans la limite des modifications autorisées) ou ne se faire que par un (ou un groupe de) « sanitiseur(s) » désigné. Dans le contexte de ce mode de réalisation, le message n'est modifiable que dans les limites définies comme étant admissibles par l'entité détentrice de la clé de signature. Ces limites peuvent comprendre non seulement les modifications possibles (typiquement l'autorisation d'effacer un attribut mais pas celle de le remplacer par un attribut valide différent), mais également les entités habilitées à apporter ces modifications. Le contrôle de l'admissibilité d'une modification de message est opéré à l'aide d'une clé de modification générée par exemple sous le contrôle de l'autorité (mais pas nécessairement détenue par elle). Autrement dit, seul un détenteur de la clé de modification peut apporter des modifications et recalculer une signature légitime. Les signatures sanitisables donnent ainsi les moyens à un signataire de déléguer à une autre entité le pouvoir de modifier un message signé, de telle sorte que le message modifié est toujours considéré comme ayant été signé par le signataire initial (puisqu'il est associé à une signature valide recalculée). Des constructions possibles de fonctions de signature sanitisable peuvent utiliser un schéma de signature standard avec utilisation d'une fonction de hachage. Pour obtenir la propriété de sanitisation, une étape préliminaire à l'utilisation de la fonction de hachage peut consister à diviser le message à signer en plusieurs parties (pouvant chacune correspondre à un attribut), selon ce qui est modifiable ou non par le dispositif électronique utilisateur, puis à utiliser une fonction de hachage caméléon sur les parties modifiables. Une fonction de hachage cryptographique standard peut ensuite être appliquée au résultat ainsi obtenu, puis une fonction de signature électronique conventionnelle peut être utilisée. La clé de modification (ou « trappe de sanitisation ») utilisée par le dispositif électronique utilisateur peut alors correspondre à la trappe de la fonction de hachage caméléon. De telles fonctions de hachage sont décrites notamment dans l'article « Chameleon Hashing and Signatures » de Hugo Krawczyk et Tal Rabin (octobre 1997), dont le contenu est incorporé par référence. Une fonction de hachage est habituellement dénuée de collisions prévisibles, c'est-à-dire qu'il n'est pas possible en pratique de trouver deux messages différents sur lesquels l'application d'une fonction de hachage donne le même résultat. Une fonction de hachage caméléon permet, à l'aide d'une trappe (une clé secrète appropriée) de construire de telles collisions. Pour cela, la sortie de la fonction de hachage est associée à une valeur dite 'aléatoire' qui va varier en fonction du message haché (et pour une collision donnée).
Le dispositif électronique utilisateur stocke également une clé de modification afin de pouvoir recalculer la signature du message une fois le message modifié. Le dispositif électronique utilisateur peut être la seule entité détentrice de cette clé de modification.
Ladite fonction de signature électronique sanitisable est associée à une clé de signature stockée dans ledit dispositif électronique certificateur (si elle n'est stockée nulle part ailleurs, la non-répudiation de la signature peut s'en trouver améliorée).
Ladite fonction est également associée à ladite clé de modification (précitée). Cette clé peut n'être stockée que dans le dispositif électronique utilisateur.
Le procédé comprend:
/a1/ la modification, par le dispositif électronique utilisateur, de l'ensemble d'attributs, ladite modification comprenant l'effacement d'attributs autres que les attributs (par exemple des attributs de date de naissance BIRTH_D et de ville de résidence CITY) requis pour l'accès anonyme audit service, /a2/ la détermination, par le dispositif électronique utilisateur, à l'aide de la clé de modification, de la signature de l'ensemble modifié, afin de permettre le contrôle ultérieur (soit dans le cadre du procédé selon le présent mode de réalisation, soit dans le cadre d'un autre procédé), par un dispositif électronique vérifieur VERIF_PC, du fait que la signature électronique de l'ensemble modifié correspond à une signature valide du dispositif électronique certificateur.
Un étudiant peut ainsi prouver, en entrant dans un cinéma, qu'il a plus de seize ans (le film qu'il souhaite voir étant interdit aux moins de seize ans) à l'aide d'un dispositif électronique utilisateur tel que sa carte (à puce) d'étudiant, et qu'il habite la ville du cinéma considéré (ce qui le cas échéant lui donne droit à une réduction) sans pour autant divulguer son adresse précise, ses noms et prénoms, ni aucune autre information personnelle non requise pour voir le film et bénéficier d'un tarif préférentiel.
Selon un mode de réalisation possible, la détermination de la signature de l'ensemble modifié par le dispositif électronique utilisateur, à l'aide de la clé de modification, est effectuée sans qu'il ne soit nécessaire que le dispositif électronique utilisateur communique avec le dispositif électronique certificateur (il peut le cas échéant exister des communications entre ces dispositifs, mais elles n'ont besoin de révéler aucune information sur les attributs stockés dans le dispositif utilisateur). De même, selon un mode de réalisation, le contrôle ultérieur par le dispositif électronique vérifieur du fait que la signature électronique de l'ensemble modifié correspond à une signature valide du dispositif électronique certificateur ne nécessite pas que le dispositif électronique vérifieur communique avec le dispositif électronique certificateur. Ainsi, le dispositif électronique certificateur, même s'il est amené à communiquer avec le dispositif électronique vérifieur, n'acquiert aucune information sur les attributs. Par exemple, la mairie n'est pas informée (et ne peut déduire des informations collectées) que telle ou telle personne est allée au cinéma à telle ou telle date et à telle ou telle heure. Selon un mode de réalisation possible, le procédé empêche la mairie de récupérer (par exemple via son dispositif électronique certificateur) des informations susceptibles d'identifier l'utilisateur, non seulement par l'absence de communication entre le dispositif électronique certificateur et d'une part le dispositif électronique utilisateur, d'autre part le dispositif électronique vérifieur, mais également par le protocole mis en œuvre par le procédé. Ce protocole peut empêcher le dispositif électronique certificateur d'établir un lien entre une demande d'autorisation d'accès par un dispositif électronique utilisateur (et/ou le traitement de cette demande d'accès par un dispositif électronique vérifieur) et des informations identifiant un dispositif électronique utilisateur particulier. Selon une variante possible, le dispositif électronique certificateur peut être amené à intervenir lors de la requête d'accès par le dispositif électronique utilisateur et de son traitement par le dispositif électronique vérifieur. Le protocole mis en œuvre peut alors empêcher le dispositif électronique certificateur de déduire, à partir des informations auxquelles il est amené à accéder, des informations d'identification de l'utilisateur. En particulier, selon un mode de réalisation, le procédé met en œuvre un protocole empêchant d'établir un lien entre la signature émise par le dispositif électronique certificateur et celle qui est déterminée par le dispositif électronique utilisateur à partir de cette précédente signature.
Ce procédé est avantageux en ce qu'il permet de préserver l'anonymat (en ne divulguant pas tous les attributs mais seulement ceux qui sont nécessaires), tout en préservant authentification (le dispositif électronique utilisateur prouve qu'il détient bien les attributs critiques pour l'accès au service). Ce procédé est également avantageux en ce qu'il permet d'empêcher le dispositif électronique utilisateur de modifier les attributs protégés autrement qu'en les effaçant (ainsi, il ne peut pas, par exemple, remplacer un nom de famille par un autre), et en ce que le dispositif électronique utilisateur ne peut effacer que les attributs autorisés (il peut lui être interdit d'effacer certains attributs). Le procédé permet également d'empêcher un dispositif électronique utilisateur de partager ses attributs avec d'autres. A cette fin, il peut être prévu que la clé de modification ne puisse pas être extraite du dispositif électronique utilisateur. Par exemple, dans le cas où ledit dispositif est une carte à puce conforme au standard ISO 7816-4, la clé de modification peut être stockée dans un fichier tel qu'un fichier de type EF (elementary file au sens de la norme ISO précitée). Ce fichier EF peut être protégé en lecture, mais accessible à l'OS (système d'exploitation) de la carte à puce (ou à une application telle qu'un softmask ou une applet javacard). Ainsi, la clé de modification peut être utilisée par le dispositif électronique utilisateur lui-même (à l'aide par exemple des fonctions prédéfinies qu'il embarque dans son système d'exploitation sécurisé), mais pas extrait (une commande de type READ_BINARY définie par l'ISO renvoyant un code d'erreur puisque l'accès en lecture est interdit). A l'aide de dispositions de ce type, un dispositif électronique utilisateur ne peut donc pas être frauduleusement combiné avec d'autres, afin de reconstituer une fausse identité (par exemple en combinant l'attribut FIRST_N d'un premier dispositif avec l'attribut LAST_N d'un deuxième dispositif et l'attribut BIRTH_D d'un troisième dispositif).
Le procédé peut être mis en œuvre à l'aide d'une suite d'instructions constituant un programme d'ordinateur exécuté par un processeur du dispositif électronique utilisateur. Mais il peut également être mis en œuvre à l'aide d'un circuit électronique dédié intégré au dispositif électronique utilisateur, tel qu'un ASIC, un FPGA (ou les variantes PAL, EPLD, PLD, CPLD, PLA, etc.) convenablement configuré (par exemple en VHDL), voire de l'électronique dédiée conçue sur mesure. Selon un mode de réalisation, un procédé de contrôle d' accès est mis en œuvre de façon à ce que la détermination de la signature de l'ensemble modifié soit opérée sans que le dispositif électronique utilisateur ne communique avec le dispositif électronique certificateur, afin de permettre le contrôle ultérieur, par le dispositif électronique vérifieur, sans que le dispositif électronique vérifieur ne communique avec le dispositif électronique certificateur, du fait que la signature électronique de l'ensemble modifié correspond à une signature valide du dispositif électronique certificateur.
On évite ainsi toute communication avec le dispositif électronique certificateur lors de la tentative d'accès au service, ce qui élimine de facto tout risque de récupération d'informations par le dispositif électronique certificateur durant cette tentative d'accès.
Selon un mode de réalisation, l'effacement d'attributs mis en œuvre par le procédé de contrôle d'accès comprend le retrait des attributs à effacer de l'ensemble d'attributs.
Ainsi, on peut par exemple recalculer que signature des seuls attributs date de naissance BIRTH_D et ville de résidence CITY, à l'exclusion des autres attributs. Si ces deux attributs occupent 20 octets chacun, on recalcule ainsi la signature d'un message de 40 octets seulement (à l'exclusion des octets alloués aux autres attributs).
Selon un mode de réalisation, l'effacement d'attributs mis en œuvre par le procédé de contrôle d'accès comprend le remplacement des attributs à effacer par des informations anonymes.
Par exemple, le procédé peut remplacer les attributs à effacer par des caractères distingués (sans corrélation avec l'attribut à remplacer). Ainsi, l'attribut de nom de famille LAST_N, qui peut par exemple contenir la chaîne de caractères « DUCHESNES », peut-il être remplacé par l'une des chaînes « XXXXXXXXX », « » (chaîne constituée de caractères d'espacement), « », « ######### », ou encore « ????????? », qui ne sont évidemment indiquées qu'à titre purement indicatif et non limitatif. Les attributs de remplacement peuvent avoir la même taille que les attributs d'origine (en nombre de bits). Dans cette hypothèse, les attributs peuvent avoir une taille prédéfinie indépendamment de leur contenu. Par exemple un attribut de nom de famille peut faire 35 caractères, indépendamment du nom de famille enregistré dans cet attribut (les noms sont alors supposés de longueur égale ou inférieure à 35 caractères, dans le cas contraire ils peuvent être tronqués à 35 caractères, ou à toute autre taille jugée opportune pour l'attribut considéré). Le nom de famille peut alors être enregistré indifféremment au début, au milieu, à la fin, ou en toute position du champ de 35 caractères réservés pour le nom de famille, les caractères non utilisés du champ pouvant être définis de façon conventionnelle (par exemple il peut s'agir de caractères d'espacement, tels que le caractère de code ASCII 32, soit 0x20).
Alternativement, il est possible de transformer le contenu d'un attribut (par exemple une chaîne de caractères ASCII) en une série de bits (ne possédant pas nécessairement de représentation visuelle selon un jeu de caractères standard, tel que l'ASCII), la valeur des bits de la série de bits étant calculée afin de ne pas modifier le résultat d'une fonction de hachage caméléon appliquée à l'ensemble d'attributs. Selon un mode de réalisation, la fonction de signature électronique sanitisable du procédé de contrôle d'accès est une fonction de signature caviardable, ou une fonction de signature électronique couplée à une fonction de hachage caméléon, ou encore une fonction de signature électronique couplée à une fonction de noircissage.
Les fonctions de signature caviardable sont des fonctions de signature électronique permettant de cacher certaines parties d'un message signé tout en gardant la signature valide. Elles peuvent s'appuyer sur la construction de certificats (sortes de cartes d'identité numérique) ayant des propriétés de caviardage (terme typographique désignant le fait d'ôter certaines parties d'un texte). Ainsi, par exemple, un étudiant peut cacher certains attributs de sa carte d'identité numérique sans la rendre inutilisable. Les fonctions de signature caviardable peuvent être une version simple des signatures sanitisables. Les fonctions de signature caviardable peuvent s'appuyer notamment sur un schéma de signature caméléon. Les fonctions de signature caviardable mises en œuvre dans le procédé peuvent noircir les attributs à cacher (tous les attributs sauf les attributs requis pour l'accès au service) en les remplaçant par des caractères distingués, mais elles peuvent également être des fonctions de signature dite supprimable (de l'anglais deletable), où l'on supprime (retire) les attributs à cacher, sans les remplacer par quoi que ce soit (même des caractères distingués). Elles permettent seulement à une entité possédant la bonne trappe, de noircir ou supprimer certaines parties bien définies d'un message, de telle sorte qu'il ne soit en pratique pas possible de déterminer ces parties à partir des parties noircies (ou supprimées - il est clair que l'on ne peut pas déterminer une information à partir de rien). Noircir une information sensible signifie remplacer cette information (telle qu'un attribut que l'on n'est pas tenu de divulguer), par des informations non corrélées, ne divulguant aucune information sensible (par exemple des caractères distingués, tels que la chaîne de caractères « ############### »).
En faisant signer un ensemble d'attributs par un dispositif électronique certificateur à l'aide d'une signature caviardable (éventuellement supprimable), et en donnant la trappe (la clé de modification) au dispositif électronique utilisateur, le dispositif électronique utilisateur est donc en mesure de noircir (ou de supprimer, suivant la technique utilisée) les attributs qu'il ne souhaite pas révéler, puis de modifier la signature de telle sorte qu'elle semble avoir été produite par le dispositif électronique certificateur. Le dispositif électronique utilisateur est ainsi, lors d'une demande d'accès à un service, anonyme vis-à-vis de l'extérieur (que ce soit vis-à-vis du dispositif électronique vérifieur, du dispositif électronique certificateur, ou de toute autre entité) et ne révèle au dispositif électronique vérifieur que les attributs demandés. Par ailleurs, dispositif électronique utilisateur n'est pas en mesure de modifier les attributs initialement signés par le dispositif électronique certificateur autrement qu'en les supprimant ou en les remplaçant par des informations « neutres » (ne correspondant à aucun attribut légitime du même type, tel que le nom d'une autre ville pour un attribut indiquant une ville) et ne peut donc pas tricher en se faisant passer pour un dispositif électronique utilisateur détenant des attributs différents. Selon un mode de réalisation, les attributs (par exemple les attributs BIRTH_D et CITY) requis pour l'accès anonyme au service dépendent dudit service, et le procédé comprend une détermination desdits attributs requis en fonction dudit service. Par exemple, le même dispositif électronique utilisateur peut permettre à son détenteur humain d'accéder à un cinéma mais également d'accéder à une piscine municipale. L'accès au cinéma avec un tarif réduit peut être subordonné à la présentation d'un attribut CITY autorisé. L'accès au cinéma pour voir des films réservés aux plus de 16 ans peut être subordonné à l'attribut BIRTH_D. Ces deux attributs peuvent donc constituer l'ensemble des attributs potentiellement modifiables. Selon un mode de réalisation, pour un accès à un cinéma, le dispositif électronique peut déterminer que seuls les attributs CITY et BIRTH_D sont susceptibles d'être requis. Le dispositif électronique utilisateur peut automatiquement effacer tous les attributs autres. Il peut alternativement laisser à l'utilisateur humain du dispositif électronique utilisateur l'opportunité d'effacer les attributs de son choix (les attributs peuvent correspondre à des attributs de l'utilisateur humain lui-même). Il peut être interdit à l'utilisateur humain d'effacer certains attributs, par exemple l'attribut BIRTH_D. Dans ce cas, la non-présentation (par effacement) de l'attribut CITY entraîne par exemple simplement l'absence de réduction, mais il n'est pas possible de ne pas présenter son âge (ceci n'est évidemment qu'un exemple, il serait possible que l'âge soit également effaçable). Selon un mode de réalisation, pour un accès à une piscine, les attributs peuvent être différents de ceux requis pour un accès au cinéma. Il peut par exemple y avoir un attribut indiquant la date du dernier certificat médical d'aptitude à la natation dûment présenté à une autorité habilitée, et il peut être prévu que seul un détenteur authentifié d'un attribut indiquant une date de moins d'un an a le droit d'entrer dans la piscine.
L'entité qui accède au service à l'aide du dispositif électronique utilisateur (par exemple une carte d'identité électronique) peut être un utilisateur humain du dispositif électronique utilisateur. Par exemple en entrant dans un cinéma, un utilisateur humain peut présenter sa carte d'identité à un lecteur NFC pour valider qu'il a le droit de voir un film en fonction des attributs de la carte d'identité. Cependant, le service peut également être fourni au dispositif électronique utilisateur. L'utilisateur humain peut alors accéder au service par l'intermédiaire du dispositif électronique. Par exemple, le dispositif électronique utilisateur peut être un téléphone portable, et le service peut être un service de vidéo à la demande, dans ce cas la vidéo est envoyée au téléphone portable (le service est donc fourni au dispositif électronique utilisateur), et l'utilisateur humain peut visualiser la vidéo sur son téléphone portable.
Pour certains services, l'utilisateur humain peut être amené à laisser son dispositif électronique utilisateur (carte d'identité, carte d'étudiant, etc.) à l'entrée, et à ne le récupérer qu'à la sortie (club de tir, bibliothèque réservée aux chercheurs et donnant accès à des ouvrages d'une valeur inestimable, visite d'un site classé confidentiel défense, etc.). Le dispositif électronique utilisateur pouvant également être un téléphone portable stockant les données personnelles requises pour l'accès (les attributs), l'accès peut être autorisé par le téléphone portable mais son utilisateur humain peut être obligé de laisser le téléphone portable à l'entrée ou de l'éteindre. Ce type de situations est également envisageable pour des dispositifs électroniques utilisateurs autres que des téléphones portables. Le dispositif électronique utilisateur peut contenir des informations personnelles imprimées (par exemple dans le cas d'une carte d'identité). Le dispositif électronique utilisateur peut contenir des informations imprimées se rapportant à des caractéristiques différentes des caractéristiques faisant l'objet des attributs stockés. Par exemple, la photo, les initiales, et le département dans lequel travaille un étudiant chercheur peuvent être imprimés sur sa carte d'étudiant, mais son nom complet, son adresse personnelle et sa date de naissance peuvent n'être disponibles que sous forme d'attributs enregistrés dans la puce de sa carte d'étudiant. Ceci est avantageux notamment dans le cas où le dispositif électronique utilisateur doit être laissé à l'entrée. Alternativement, le dispositif électronique utilisateur peut comprendre les mêmes informations sous forme d'attributs stockés et de données imprimées, mais peut être remis dans une consigne fermée en échange de la clé unique d'un cadenas de la consigne, ou encore, dans le cas d'une carte, être avalé par un lecteur de carte (à la manière d'un distributeur de billet), stocké à l'intérieur, et restitué sur présentation d'un identifiant et d'un code PIN de la carte (sans que personne d'autre que le titulaire n'ait l'opportunité de voir ce qui est imprimé sur la carte), après délivrance du service à l'utilisateur humain.
Selon un mode de réalisation, le procédé de contrôle d'accès comprend la certification, par le dispositif électronique certificateur, de l'ensemble d'attributs à l'aide de la fonction de signature électronique sanitisable. Selon un mode de réalisation, le procédé de contrôle d'accès comprend le contrôle, par le dispositif électronique vérifieur, du fait que la signature électronique de l'ensemble modifié correspond à une signature valide du dispositif électronique certificateur.
Selon un mode de réalisation, un dispositif électronique utilisateur ID_CARD est agencé pour stocker une clé de modification MOD_K ainsi qu'un ensemble certifié d'attributs FIRST_N, LAST_N, BIRTH_D, BIRTH_P, ADDR, CITY, STATE, CSHIP.
Le dispositif électronique utilisateur peut être une carte à puce, ce qui est avantageux pour la sécurité. Il peut s'agir d'une carte à puce quelconque, notamment d'une carte à contact (par exemple au standard ISO 7816-2), d'une carte sans contact (par exemple une carte au standard MiFare, au standard ISO 14443, ou encore comprenant une interface NFC quelconque), d'une carte mixte à contact et sans contact avec une puce commune aux deux interfaces ou bien avec une puce distincte pour chaque interface contact et sans contact, etc. La carte peut être au format ID-1 de l'ISO-7810, au format ID-000 de cette même norme (format dit « plug-in »), au format microSIM, ou à tout autre format adapté (il peut s'agir d'un document d'identité en papier au format d'un passeport conventionnel, etc.). La carte peut comprendre une puce de carte bancaire, de carte SIM (l'acronyme SIM, de l'anglais Subscriber Identity Module, désigne de façon générique toutes les variantes CSIM, USIM, UICC etc.), de carte PKI, de carte d'accès, de carte de santé, de carte de transport, de carte d'identité, de passeport, de chronotachygraphe, etc. En particulier, le dispositif électronique utilisateur peut être une carte SIM équipée d'un circuit électronique capable de gérer des communications sans fil de type NFC. Comme le format de petite taille d'une carte SIM rend difficile l'intégration d'une antenne, la carte SIM peut comprendre un contact conforme au standard SWP (Single Wire Protocol) permettant à la SIM de se raccorder à une antenne intégrée au téléphone portable et de fonctionner de façon autonome. Autrement dit, la carte peut fonctionner indépendamment du fait que le portable soit allumé ou éteint et que la batterie du téléphone portable soit chargée ou vide. La carte peut en effet être alimentée par le champ électromagnétique généré à cet effet par le lecteur NFC avec lequel elle entre en communication (un lecteur NFC intégré au dispositif électronique vérifieur, ou communiquant avec lui), via l'antenne NFC du téléphone portable. Ceci permet de mettre en place un environnement mieux contrôlé et plus sécurisé que celui du téléphone portable qui est souvent beaucoup plus complexe et ouvert (permettant le chargement d'applications tierces, et éventuellement de virus).
Le dispositif électronique utilisateur peut également être une carte mémoire dotée d'un processeur (de type secureMMC, etc.), une clé USB, etc. Le dispositif électronique utilisateur peut également être un ordinateur quelconque.
L'ensemble d'attributs stocké dans le dispositif électronique utilisateur est certifié par un dispositif électronique certificateur CERT_SRV à l'aide d'une fonction de signature électronique sanitisable. Ladite fonction est associée à une clé de signature SIG_K stockée dans ledit dispositif électronique certificateur ainsi qu'à ladite clé de modification MOD_K. Le dispositif électronique utilisateur est agencé pour modifier l'ensemble d'attributs en effaçant des attributs autres que les attributs BIRTH_D et CITY requis pour l'accès anonyme audit service, et pour déterminer, à l'aide de la clé de modification, la signature de l'ensemble d'attributs modifié. Ceci permet le contrôle ultérieur, par un dispositif électronique vérifieur VERIF_PC (qui peut être un ordinateur de type PC, un serveur, un lecteur NFC comprenant un circuit pour communiquer avec le dispositif électronique utilisateur, etc.), du fait que la signature électronique de l'ensemble modifié correspond à une signature valide du dispositif électronique certificateur.
Selon un mode de réalisation, un dispositif électronique utilisateur est agencé pour déterminer la signature de l'ensemble d'attributs modifié sans communiquer avec le dispositif électronique certificateur. Ceci permet le contrôle ultérieur, par le dispositif électronique vérifieur, sans que ce dispositif électronique vérifieur ne communique lui non plus avec le dispositif électronique certificateur, du fait que la signature électronique de l'ensemble modifié correspond à une signature valide du dispositif électronique certificateur. Le dispositif électronique certificateur n'étant a aucun moment impliqué dans la requête d'accès par le dispositif électronique utilisateur ni le traitement de cette requête par le dispositif électronique vérifieur, ce dispositif électronique certificateur ne peut matériellement collecter aucune information sur le dispositif électronique utilisateur (et sur son détenteur humain) à l'occasion de cette transaction (et ce que la transaction aboutisse ou non à une approbation de l'accès). Selon un mode de réalisation, un dispositif électronique utilisateur est agencé pour effacer les attributs autres que les attributs requis pour l'accès anonyme audit service en retirant lesdits attributs à effacer de l'ensemble d'attributs. Selon un mode de réalisation, un dispositif électronique utilisateur est agencé pour effacer les attributs autres que les attributs requis pour l'accès anonyme audit service en remplaçant lesdits attributs à effacer par des informations anonymes.
Selon un mode de réalisation, la fonction de signature électronique sanitisable d'un dispositif électronique utilisateur est de l'un des types suivants: une fonction de signature caviardable, ou une fonction de signature électronique conventionnelle couplée à une fonction de hachage caméléon, ou encore une fonction de signature électronique conventionnelle couplée à une fonction de noircissage.
Selon un mode de réalisation, les attributs (par exemple BIRTH_D et CITY) requis pour l'accès anonyme au service dépendent dudit service, le dispositif électronique utilisateur étant agencé pour déterminer lesdits attributs requis en fonction dudit service.
Selon un mode de réalisation, un système de contrôle d' accès anonyme à un service comprend un dispositif électronique utilisateur selon un mode de réalisation, et au moins l'un des deux dispositifs suivants:
- un dispositif électronique certificateur CERT_SRV agencé pour certifier un ensemble d'attributs FIRST_N, LAST_N, BIRTH_D, BIRTH_P, ADDR, CITY, STATE et CSHIP à l'aide d'une fonction de signature électronique sanitisable, ladite fonction étant associée à une clé de signature stockée dans le dispositif électronique certificateur ainsi qu'à une clé de modification, de manière à permettre au dispositif électronique utilisateur, lorsqu'il a préalablement stocké l'ensemble d'attributs certifié ainsi que la clé de modification, de modifier l'ensemble d'attributs en effaçant des attributs autres que les attributs BIRTH_D et CITY requis pour l'accès anonyme audit service, et de déterminer, à l'aide de la clé de modification, la signature de l'ensemble modifié,
- un dispositif électronique vérifieur VERIF_PC agencé pour recevoir du dispositif électronique utilisateur un ensemble certifié d'attributs BIRTH_D, CITY, et pour contrôler que la signature électronique de l'ensemble reçu correspond à une signature valide d'un dispositif électronique certificateur CERT_SRV.
Le dispositif électronique utilisateur peut être agencé pour communiquer avec le dispositif électronique certificateur via un réseau filaire ou sans fil (par exemple de type Ethernet, WiFi, ATM, ADSL, satellite, Wimax, réseaux cellulaires 1G, 2G, 3G, 4G etc.), éventuellement par l'intermédiaire d'un hôte (par exemple un ordinateur personnel ou un téléphone portable auquel on connecte le dispositif électronique utilisateur). Le dispositif électronique vérifieur peut également être agencé pour communiquer avec le dispositif électronique certificateur via un réseau filaire ou sans fil (par exemple de type Ethernet, Wi-Fi, ATM, ADSL, satellite, Wimax, réseaux cellulaires 1G, 2G, 3G, 4G etc.). Cependant, dans le cadre d'une transaction d'autorisation d'accès, le dispositif électronique utilisateur et le dispositif électronique vérifieur peuvent être agencés pour ne communiquer ni l'un ni l'autre avec le dispositif électronique certificateur. Le dispositif électronique utilisateur et le dispositif électronique vérifieur peuvent être agencés pour communiquer entre eux à aide de protocoles filaires ou sans fil qui peuvent être des protocoles à courte portée (ZigBee, Bluetooth, infrarouge tel que l'irDA, connexion USB, connexion FireWire - IEEE 1394, connexion Sata ou eSata, connexion CPL, connexion Wireless USB, connexion propriétaire, ISO 7816, ISO 14443A ou ISO 14443B, Wi-Fi, etc.).
Le dispositif électronique certificateur peut comprendre des éléments de redondance, par exemple des disques durs ou des mémoires protégées selon une technique RAID (pour redundant array of independent disks) bien connue, protégeant ainsi contre la perte de la clé de signature sans pour autant imposer de stockage de cette clé hors du dispositif électronique certificateur.
Selon un mode de réalisation, un programme d'ordinateur est agencé pour mettre en œuvre un procédé selon un mode de réalisation lorsqu'il est exécuté par un processeur. Le processeur peut être un processeur du dispositif électronique utilisateur, ou un processeur d'un module de sécurité inséré dans un tel dispositif (par exemple un processeur de carte à puce SIM insérée dans un téléphone portable). Le programme d'ordinateur peut être écrit en langage C, en Java, en C++, en C#, en Basic (et ses multiples variantes), en assembleur, ou en tout langage approprié. Le programme d'ordinateur peut comprendre des instructions adaptées pour tirer partie d'un support matériel dédié du processeur, tel qu'un cryptoprocesseur permettant d'accélérer certains calculs (tels que des exponentiations modulaires) qui sinon peuvent être plus lents à mettre en œuvre sur la seule base d'un jeu d'instruction standard de processeur conventionnel. Selon un mode de réalisation, un support de stockage non transitoire lisible par ordinateur stocke un programme selon un mode de réalisation possible. Le support de stockage peut être par exemple une carte à puce, une clé USB, un microcontrôleur doté d'une mémoire non volatile (EEPROM, Flash, ROM, etc.), une puce mémoire, une carte mémoire, un support de stockage magnétique (disque dur, bande magnétique, disquette, etc.), ou tout autre forme de stockage adaptée.
Des modes de réalisation spécifiques particulièrement avantageux sont décrits plus précisément ci-après.
Les participants d'un système d'accréditation anonyme sont des organisations (disposant de dispositifs électroniques certificateurs), des utilisateurs (disposant de dispositifs électroniques certificateurs), et des vérifieurs (disposant de dispositifs électroniques vérifieurs). Les organisations délivrent des accréditations (par exemple des attributs certifiés) aux utilisateurs, qui peuvent les utiliser de manière anonymes auprès de vérifieurs (par exemple des fournisseur de services). Un système d'accréditation anonyme peut mettre en œuvre les fonctions suivantes. AC:Setup :
La fonction AC: Setup a pour but de générer les paramètres du système. Elle prend en entrée un paramètre de sécurité
Figure imgf000018_0002
(qui peut correspondre à la taille des éléments cryptographiques à manipuler) et retourne les paramètres param (éléments d'un groupe et scalaires qui sont publics).
AC:OrgKeyGen, AC:UserKeyGen :
Les fonctions OrgKeyGen et UserKeyGen génèrent des clefs (secrètes et/ou publiques) pour, respectivement, les organisations et les utilisateurs.
AC:Obtain
Figure imgf000018_0003
AC:Issue.
Ces deux fonctions forment un protocole exécuté entre un utilisateur souhaitant obtenir une accréditation et une organisation délivrant des accréditations. La fonction Obtain, exécutée par l'utilisateur, prend en entrée une clef secrète skU et une clef publique d'organisation pkO. La fonction Issue, exécutée par l'organisation, prend en entrée une clef secrète d'organisation skO, une donnée publique utilisateur pkU et une liste d'attributs (nom, date de naissance, étude, etc.) qu'elle souhaite certifier à l'utilisateur
Figure imgf000018_0004
A la fin du protocole, l'utilisateur U a obtenu une accréditation C (ou bien un message d'erreur
Figure imgf000018_0001
a été généré).
Figure imgf000018_0005
La double flèche
Figure imgf000018_0006
symbolise les interactions entre les différents programmes qui s'exécutent et les flèches
Figure imgf000018_0007
indiquent les sorties des fonctions.
AC:Show
Figure imgf000018_0008
AC:Verify. Ces deux fonctions forment un protocole exécuté entre un utilisateur souhaitant justifier la possession d'une accréditation et un vérifieur souhaitant vérifier cette possession.
La fonction Show, exécutée par l'utilisateur, prend en entrée une clef secrète skU, une clef publique pkO, une liste de messages et une accréditation C. La fonction Verify, exécutée par
Figure imgf000018_0009
le vérifieur, prend en entrée une clef publique pkO et une liste M de messages telle que
Figure imgf000018_0010
A la fin du protocole, la fonction Verify retourne un bit
Figure imgf000018_0011
indiquant s'il accepte la preuve de possession de l'utilisateur.
Figure imgf000018_0012
Le protocole de vérification est public: il ne nécessite pas de clef secrète pour être exécuté.
Les notations suivantes sont utilisées. Un message m est, génériquement, une chaîne de bits de longueur
Figure imgf000019_0003
(c'est-à-dire une suite de bits 0 ou 1, de longueur arbitraire comme l'indique l'étoile *). On sépare les messages en blocs
Figure imgf000019_0008
où N est le nombre de blocs et un symbole de concaténation.
Les portions de message que l'utilisateur pourra modifier, ou supprimer selon les cas, sont désignées par un sous-ensemble d indice
Figure imgf000019_0004
La partie fixe
Figure imgf000019_0009
d'un message
Figure imgf000019_0005
d'après un ensemble de portions admissibles ADM est donnée par la fonction
Figure imgf000019_0001
où
Figure imgf000019_0006
Les instructions de modification MOD, étant donnée une assignation de portions (ou blocs) admissibles (c'est-à-dire modifiables) ADM pour un message
Figure imgf000019_0007
sont données par une liste de paires d'indices et de messages
Figure imgf000019_0002
(c'est-à-dire que le bloc modifié m'j a la même taille, en nombre de bits, que le bloc d'origine), pour tout
Figure imgf000019_0010
Figure imgf000019_0013
Ces instructions dénotent le fait que le jeme bloc de message mj doit être remplacé par le nouveau bloc m'j. Dans le cas des signatures caviardables, une instruction de modification
Figure imgf000019_0011
devient
Figure imgf000019_0012
le symbole (« bot », de l'anglais bottom) indiquant que le jeme bloc de message doit être noirci ou supprimé.
La notation
Figure imgf000019_0014
indique que les instructions de modification MOD sont compatibles avec les portions admissibles ADM. C'est-à-dire que ces instructions ne demandent pas de modifier un bloc qui n'a pas été désigné comme modifiable.
On note
Figure imgf000019_0015
le message
Figure imgf000019_0016
résultant de la sanitisation du message m selon les instructions de modification MOD.
Soit ADM des portions admissibles et deux messages accompagnés d'instructions de modification. Si les messages sont identiques une fois que la sanitisation a été appliquée, alors on note
Figure imgf000019_0018
La notation
Figure imgf000019_0019
indique qu'il existe un sous-ensemble d'indices
Figure imgf000019_0020
tel que
Figure imgf000019_0021
pour tout
Figure imgf000019_0022
Dans un schéma de signature sanitisable, noté SAN, deux types de participants sont présents: les signeurs et les sanitiseurs. Un schéma de signature sanitisable est donné par les cinq fonctions suivantes.
SAN:Setup. La fonction Setup génère les paramètres du système. Elle prend en entrée un paramètre de sécurité λ (qui correspond à la taille des éléments cryptographiques à manipuler) et retourne les paramètres param (éléments d'un groupe et scalaires qui sont publics).
SAN:SigKeyGen, SAN:SanKeyGen.
Les fonctions SigKeyGen et SanKeyGen génèrent des clefs pour, respectivement, les signeurs et les sanitiseurs.
SAN:Sign.
La fonction de signature Sign prend en entrée une clef secrète un sanitiseur désigné par
Figure imgf000020_0004
Figure imgf000020_0002
l'indice à qui il souhaite déléguer le droit de modifier le message, un message m et des portions admissibles ADM. Il génère une signature
Figure imgf000020_0001
(ou un message d'erreur
Figure imgf000020_0003
utilisant la même notation que pour la fonction de noircissage / suppression mais il s'agit ici d'une notion différente).
Figure imgf000020_0007
SAN:Sanitize.
La fonction de sanitisation Sanitize prend en entrée une clef secrète de sanitiseur la clef
Figure imgf000020_0005
publique du signeur le message m, la signature
Figure imgf000020_0006
et des modifications d'instructions MOD. Elle
Figure imgf000020_0008
génère un message
Figure imgf000020_0009
et une signature
Figure imgf000020_0010
sur ce message (ou un message d'erreur
Figure imgf000020_0011
).
Figure imgf000020_0012
SAN:Verify.
La fonction de vérification Verify prend en entrée la clef publique du signeur le message m
Figure imgf000020_0014
et la signature . Elle retourne un bit d'acceptation
Figure imgf000020_0013
indiquant si la signature est valide ou non.
La procédure de vérification est publique: elle ne nécessite pas de clef secrète pour être exécutée.
Il existe différentes versions de signatures sanitisables. Les propriétés fonctionnelles et de sécurité de ces différentes versions varient selon les versions. Dans le cadre des modes réalisations décrits ci- dessous, le procédé s'appuie sur des signatures sanitisables remplissant les conditions suivantes. D'autres propriétés pourraient être ajoutées, mais ne sont pas indispensables. Il s'agit de conditions nécessaires pour obtenir les propriétés recherchées pour les accréditations anonymes dans le cadre de ces modes de réalisation (bien sûr, d'autres modes de réalisation moins sécurisés sont envisageables).
P1A
La vérification d'une signature ne doit pas nécessiter la clé publique du sanitiseur qui a le droit de modifier le couple message/signature que l'on a. Ceci nous permet d'obtenir l'anonymat du sanitiseur (et donc de l'utilisateur dans notre système d'accréditations). En effet, même si la clé publique n'était pas liée à un individu formellement identifié, le simple fait qu'elle existe permettrait au minimum de suivre les transactions de l'utilisateur associé à cette clé publique, et pour peu que l'une des transactions révèle son identité, il serait éventuellement possible de lui associer toutes les transactions correspondantes.
P1B
Alternativement, la clé du sanitiseur est nécessaire, mais elle est cachée au moment de la vérification. A cette fin, le procédé s'appuie sur une preuve à divulgation nulle de connaissance (preuve dite « zero-knowledge ») pour cacher la clé du sanitiseur, tout en prouvant que la signature obtenue est valide. P2
L'utilisateur/sanitiseur ne doit pas être capable de remplacer l'un de ses attributs par quelque chose qui l'arrange (par exemple remplacer sa véritable ville de résidence par celle dont il souhaite profiter des services). En pratique, le sanitiseur ne doit pas être capable de remplacer une partie admissible d'un message signé par ce qu'il veut. Il faut par conséquent un système qui limite les modifications que peut apporter le sanitiseur.
P3
Si un message initialement signé est modifié deux fois de la même façon par le même sanitiseur, cela doit être fait de façon non traçable: on ne doit pas savoir qu'il s'agit de la même entité.
P4
Le rejeu d'une signature sanitisée doit être infaisable. Cette phase doit contenir un aléa maîtrisé à la fois par le sanitiseur et le vérifieur.
L'obtention d'une accréditation peut s'effectuer selon le schéma suivant
Figure imgf000021_0001
L'utilisation d'une accréditation peut, quant à elle, obéir au schéma suivant
Figure imgf000022_0001
Un système d'accréditation anonyme AC selon un mode de réalisation s'appuie sur un schéma de signature sanitisable SAN respectant les propriétés PIA ou PIB, ainsi que P2 à P4, énoncées ci-dessus.
La procédure AC: Setup de génération des paramètres du système d'accréditation anonyme est la procédure SAN:Setup de génération des paramètres du schéma de signature sanitisable.
La procédure AC:UserKeyGen de génération des clefs des utilisateurs du système d'accréditation anonyme est la procédure SAN:SanKeyGen de génération des clefs des sanitiseurs du schéma de signature sanitisable.
La procédure AC:OrgKeyGen de génération des clefs des organisations du système d'accréditation anonyme est la procédure SAN:SigKeyGen de génération des clefs des signeurs du schéma de signature sanitisable.
Le protocole AC:Obtain
Figure imgf000022_0005
AC:Issue d'obtention d'une accréditation anonyme par un utilisateur est exécuté de la manière suivante.
Supposons que le document à signer
Figure imgf000022_0002
soit de longueur t (t bits), l'organisation
O sépare m en N blocs de longueurs respectives
Figure imgf000022_0003
et spécifie un sous-ensemble d'indices
Figure imgf000022_0004
à sa convenance. Un champ spécifique, d'indice n, est choisi. L'organisation O génère alors une signature à l'aide de la clef publique pku
Figure imgf000022_0006
de l'utilisateur U et envoie la signature à U. L'utilisateur U enregistre
Figure imgf000022_0007
comme une accréditation de O sur le message m.
Le document à accréditer peut correspondre à une concaténation des noms (ou identifiants) des champs (par exemple LAST_N, ADDR, etc.) et à la valeur de chacun de ces champs dans le cas d'espèce considéré (par exemple « Lescuyer », « Caen », etc.). Les parties admissibles peuvent correspondre aux valeurs des champs, et exclure les identifiants des champs (dans cette hypothèse, l'utilisateur ne doit pas pouvoir modifier LAST_N mais doit pouvoir modifier « Lescuyer », du moins il doit pouvoir le modifier d'une manière autorisée). La clé publique de l'utilisateur qui obtient l'accréditation correspond à sa clé publique de sanitiseur. Le protocole AC:Show
Figure imgf000022_0008
AC:Verify d'utilisation d'une accréditation par un utilisateur U auprès d'un vérifieur V peut être exécuté de la manière suivante. Supposons qu'un vérifieur V souhaite vérifier qu'un utilisateur U possède une accréditation certifiant la possession d'un ensemble d'attributs M. Supposons que l'utilisateur U possède une accréditation sur un document
Figure imgf000023_0014
Figure imgf000023_0015
(c'est-à-dire que le document m possède les attributs demandés).
Dans un premier temps, le vérifieur envoie une valeur aléatoire r à l'utilisateur U. Cette valeur r peut être par exemple la concaténation de données propres à la vérification et à l'heure courante. Dans un second temps, l'utilisateur U sanitise le document selon les instructions de modification suivantes
Figure imgf000023_0001
et calcule
Figure imgf000023_0002
L'utilisateur envoie
Figure imgf000023_0004
au vérifieur. Le vérifieur vérifie que la signature
Figure imgf000023_0003
est une signature valide de message
Figure imgf000023_0005
grâce à la clef publique de l'organisation O. Il renvoie 1 si c'est le cas et 0 sinon.
Un mode de réalisation est décrit plus précisément ci-dessous dans le cas d'une fonction de sanitisation particulièrement avantageuse.
Ce mode de réalisation s'applique à des documents quelconques. Un document peut être défini comme une chaîne quelconque de bits. L'espace des messages est donc
Figure imgf000023_0006
Cependant, tous les documents à signer comportent un champ réservé de longueur fixe
Figure imgf000023_0007
Ce mode de réalisation s'appuie sur une fonction de hachage qui permet de hacher uniformément dans
Figure imgf000023_0008
Selon ce mode de réalisation, les blocs de messages à noircir sont noircis d'une façon unique. Un bloc de longueur
Figure imgf000023_0009
est toujours remplacé par un bloc de même taille. Le noircissage d'un bloc peut par exemple consister en un remplacement de ce bloc par une suite de bits 0 de même longueur que ce bloc.
Ce mode de réalisation se place dans le cadre d'un environnement bilinéaire symétrique
Figure imgf000023_0010
pour effectuer les calculs.
Dans
Figure imgf000023_0011
p est un nombre premier, sont des groupes algébriques d'ordre p,
Figure imgf000023_0012
et e est une application bilinéaire
Figure imgf000023_0013
Il existe de nombreux algorithmes bien connus pour générer de tels environnements de calcul.
Les actions suivantes sont mises en œuvre afin de créer un environnement de calcul global pour le système : 1. Générer un environnement bilinéaire symétrique
Figure imgf000024_0002
2. Choisir des générateurs (le signe $ au dessus de la flèche
Figure imgf000024_0003
désignant un choix opéré de façon aléatoire)
3. Choisir deux fonctions de hachage
Figure imgf000024_0004
4. Retourner les paramètres du système
Figure imgf000024_0005
Le signeur génère ses clefs en mettant en œuvre les actions suivantes:
1. Choisir deux aléas
Figure imgf000024_0006
2. Calculer
Figure imgf000024_0007
3. Choisir une clef pour une fonction pseudo-aléatoire
Figure imgf000024_0008
4. Retourner la paire de clefs
Figure imgf000024_0009
Le sanitiseur s'enregistre auprès d'un signeur, en mettant en œuvre les actions suivantes:
1. Générer deux aléas
Figure imgf000024_0010
(dans le cas où le signeur est une carte à puce, la génération peut faire appel à un générateur aléatoire matériel, fournissant des aléas d'une qualité généralement supérieure à celle des générateurs purement algorithmiques, et s'appuyant par exemple sur un échantillonnage d'un bruit analogique mesuré au sein de la puce, traité éventuellement par un cryptoprocesseur) 2. Calculer
Figure imgf000024_0011
3. Donner
Figure imgf000024_0012
au sanitiseur.
Chacune des parties (le signeur et le sanitiseur), enregistre alors ces données en tant que certificat d'appartenance au système
Figure imgf000024_0013
Le protocole d'obtention d'une accréditation entre un utilisateur, déjà enregistré, et une organisation, est mis en œuvre de la façon suivante.
Le protocole rassemble les données utilisateurs en un document
Figure imgf000024_0014
de longueur t (en bits). L'organisation sépare le document
Figure imgf000024_0015
blocs de longueurs respectives
Figure imgf000024_0001
et spécifie un sous-ensemble d'indices
Figure imgf000024_0016
désignant les portions de messages que l'utilisateur pourra cacher. Le protocole choisit un champ spécifique (champ réservé), d'indice et de longueur
Figure imgf000024_0017
Le protocole définit , ce qui signifie que le champ réservé
Figure imgf000024_0018
peut être modifié à loisir par l'utilisateur tandis que les autres blocs modifiables ne peuvent être que noircis. La clef secrète
Figure imgf000025_0003
Le sanitiseur i est représenté par son certificat
Figure imgf000025_0004
Ces différentes étapes (rassembler, séparer, spécifier, choisir, définir, représenter) peuvent être mises en œuvre par un dispositif distinct du dispositif électronique certificateur, également sous le contrôle de l'organisation, ou par le dispositif électronique certificateur lui-même.
Le signeur met en œuvre les actions suivantes.
1. Générer deux aléas
Figure imgf000025_0005
grâce à la fonction pseudo-aléatoire :
Figure imgf000025_0006
2. Générer
Figure imgf000025_0007
3. Hacher le message
Figure imgf000025_0001
4. Pour tout
Figure imgf000025_0008
exécuter les actions suivantes:
(a) Hacher
Figure imgf000025_0002
(b) Calculer
Figure imgf000025_0009
5. Calculer :
Figure imgf000025_0010
6. Hacher le message :
Figure imgf000025_0011
7. Calculer :
Figure imgf000025_0012
8. Poser :
Figure imgf000025_0013
Après avoir exécuté ces calculs (par exemple avec le dispositif électronique certificateur), l'organisation donne à l'utilisateur. Celui-ci enregistre comme accréditation sur le message m.
Figure imgf000025_0016
Figure imgf000025_0017
Le protocole permettant à l'utilisateur d'utiliser une accréditation afin d'obtenir un accès à un service auprès d'un fournisseur de service que l'on appellera le vérifieur est décrit ci-dessous. 'accréditation peut avoir été délivrée sur un message par l'organisation identifiée par
Figure imgf000025_0015
Figure imgf000025_0014
selon les modalités précitées. L'utilisateur possède un certificat
La signature est de la forme :
Figure imgf000026_0005
L'utilisateur souhaite cacher un sous-ensemble d'attributs
Figure imgf000026_0006
du document
Figure imgf000026_0007
est le sous-ensemble d'indices des blocs de messages que l'utilisateur à le droit de noircir.
On désigne par
Figure imgf000026_0011
dans lequel chaque portion
Figure imgf000026_0008
a été noircie. Dans un premier temps, le vérifieur envoie à l'utilisateur une valeur aléatoire
Figure imgf000026_0009
(pour laquelle un champ réservé est prévu). On peut, par exemple, hacher dans
Figure imgf000026_0010
la concaténation de données liées au fournisseur de service et la date courante.
Dans un second temps, l'utilisateur exécute les actions suivantes :
1. Générer
Figure imgf000026_0012
2. Hacher le message
Figure imgf000026_0013
3. Pour tout
Figure imgf000026_0014
, exécuter les actions suivantes :
(a) Hacher
Figure imgf000026_0001
(b) Calculer
Figure imgf000026_0015
4. Calculer :
Figure imgf000026_0002
5. Hacher le message :
Figure imgf000026_0003
6. Calculer :
Figure imgf000026_0016
7. Poser :
Figure imgf000026_0017
L'utilisateur envoie alors au vérifieur.
Figure imgf000026_0018
Dans un troisième temps, le vérifieur, ayant reçu des données de la forme :
Figure imgf000026_0004
exécute les actions suivantes:
1. Hacher le message
Figure imgf000026_0019
2. Hacher le message :
Figure imgf000026_0020
Figure imgf000027_0002
3. Récupérer présent dans et poser mettre en œuvre
Figure imgf000027_0003
Figure imgf000027_0004
les actions suivantes:
(a) Si la portion
Figure imgf000027_0008
est différente de la partie noire, alors
i. Si
Figure imgf000027_0005
arrêter l'algorithme et retourner 0, sinon, continuer. ii. Mettre a jour
Figure imgf000027_0006
iii. Hacher
Figure imgf000027_0007
4. Tester les équations suivantes :
Figure imgf000027_0001
Si toutes ces équations sont vérifiées, le vérifieur retourne 1, sinon, il retourne 0.
Bien entendu, les exemples donnés ci-dessus ne sont nullement limitatifs.
Les modes de réalisation concernant les procédés peuvent être transposés aux dispositifs, et réciproquement.

Claims

Revendications
1. Procédé de contrôle d'accès anonyme à un service, dans lequel, un dispositif électronique utilisateur (ID_CARD) stockant un ensemble certifié d'attributs (FIRST_N, LAST_N, BIRTH_D, BIRTH_P, ADDR, CITY, STATE, CSHIP) et une clé de modification (MOD_K), ledit ensemble ayant été certifié par un dispositif électronique certificateur (CERT_SRV) à l'aide d'une fonction de signature électronique sanitisable, ladite fonction étant associée à une clé de signature (SIG_K) stockée dans ledit dispositif électronique certificateur ainsi qu'à ladite clé de modification (MOD_K), le procédé comprend : /al/ la modification, par le dispositif électronique utilisateur, de l'ensemble d'attributs, ladite modification comprenant l'effacement d'attributs autres que les attributs (BIRTH_D, CITY) requis pour l'accès anonyme audit service,
/a2/ la détermination, par le dispositif électronique utilisateur, à l'aide de la clé de modification, de la signature de l'ensemble modifié, afin de permettre le contrôle ultérieur, par un dispositif électronique vérifieur (VERIF_PC), du fait que la signature électronique de l'ensemble modifié correspond à une signature valide du dispositif électronique certificateur.
2. Procédé de contrôle d'accès selon la revendication 1, dans lequel la détermination de la signature de l'ensemble modifié est opérée sans que le dispositif électronique utilisateur ne communique avec le dispositif électronique certificateur, afin de permettre le contrôle ultérieur, par le dispositif électronique vérifieur, sans que le dispositif électronique vérifieur ne communique avec le dispositif électronique certificateur, du fait que la signature électronique de l'ensemble modifié correspond à une signature valide du dispositif électronique certificateur.
3. Procédé de contrôle d'accès selon la revendication 1, dans lequel l'effacement d'attributs comprend le retrait des attributs à effacer de l'ensemble d'attributs.
4. Procédé de contrôle d'accès selon la revendication 1, dans lequel l'effacement d'attributs comprend le remplacement des attributs à effacer par des informations anonymes.
5. Procédé de contrôle d'accès selon la revendication 1, dans lequel la fonction de signature électronique sanitisable est une fonction de signature caviardable, ou une fonction de signature électronique couplée à une fonction de hachage caméléon, ou encore une fonction de signature électronique couplée à une fonction de noircissage.
6. Procédé de contrôle d'accès selon la revendication 1, dans lequel les attributs (BIRTH_D, CITY) requis pour l'accès anonyme audit service dépendent dudit service, et dans lequel le procédé comprend une détermination desdits attributs requis en fonction dudit service.
7. Procédé de contrôle d'accès selon la revendication 1, comprenant :
/a0/ la certification, par le dispositif électronique certificateur (CERT_SRV), de l'ensemble d'attributs (FIRST_N, LAST_N, BIRTH_D, BIRTH_P, ADDR, CITY, STATE, CSHIP) à l'aide de ladite fonction de signature électronique sanitisable.
8. Procédé de contrôle d'accès selon la revendication 1, comprenant :
/a3/ le contrôle, par le dispositif électronique vérifieur (VERIF_PC), du fait que la signature électronique de l'ensemble modifié correspond à une signature valide du dispositif électronique certificateur.
9. Dispositif électronique utilisateur (ID_CARD) agencé pour stocker une clé de modification (MOD_K) ainsi qu'un ensemble certifié d'attributs (FIRST_N, LAST_N, BIRTH_D, BIRTH_P, ADDR, CITY, STATE, CSHIP), l'ensemble d'attributs stocké étant certifié par un dispositif électronique certificateur (CERT_SRV) à l'aide d'une fonction de signature électronique sanitisable, ladite fonction étant associée à une clé de signature (SIG_K) stockée dans ledit dispositif électronique certificateur ainsi qu'à ladite clé de modification (MOD_K), le dispositif électronique utilisateur étant agencé pour modifier l'ensemble d'attributs en effaçant des attributs autres que les attributs (BIRTH_D, CITY) requis pour l'accès anonyme audit service, et pour déterminer, à l'aide de la clé de modification, la signature de l'ensemble d'attributs modifié, afin de permettre le contrôle ultérieur, par un dispositif électronique vérifieur (VERIF_PC), du fait que la signature électronique de l'ensemble modifié correspond à une signature valide du dispositif électronique certificateur.
10. Dispositif électronique utilisateur selon la revendication 9, le dispositif électronique utilisateur étant agencé pour déterminer la signature de l'ensemble d'attributs modifié sans communiquer avec le dispositif électronique certificateur, afin de permettre le contrôle ultérieur, par le dispositif électronique vérifieur, sans que ce dispositif électronique vérifieur ne communique avec le dispositif électronique certificateur, du fait que la signature électronique de l'ensemble modifié correspond à une signature valide du dispositif électronique certificateur.
11. Dispositif électronique utilisateur selon la revendication 9, agencé pour effacer les attributs autres que les attributs requis pour l'accès anonyme audit service en retirant lesdits attributs à effacer de l'ensemble d'attributs.
12. Dispositif électronique utilisateur selon la revendication 9, agencé pour effacer les attributs autres que les attributs requis pour l'accès anonyme audit service en remplaçant lesdits attributs à effacer par des informations anonymes.
13. Dispositif électronique utilisateur selon la revendication 9, dans lequel la fonction de signature électronique sanitisable est de l'un des types suivants : une fonction de signature caviardable, ou une fonction de signature électronique conventionnelle couplée à une fonction de hachage caméléon, ou encore une fonction de signature électronique conventionnelle couplée à une fonction de noircissage.
14. Dispositif électronique utilisateur selon la revendication 9, dans lequel, les attributs (BIRTH_D, CITY) requis pour l'accès anonyme audit service dépendant dudit service, le dispositif électronique utilisateur est agencé pour déterminer lesdits attributs requis en fonction dudit service.
15. Système de contrôle d'accès anonyme à un service, comprenant un dispositif électronique utilisateur selon la revendication 9, et au moins l'un des deux dispositifs suivants :
- un dispositif électronique certificateur (CERT_SRV) agencé pour certifier un ensemble d'attributs (FIRST_N, LAST_N, BIRTH_D, BIRTH_P, ADDR, CITY, STATE, CSHIP) à l'aide d'une fonction de signature électronique sanitisable, ladite fonction étant associée à une clé de signature stockée dans le dispositif électronique certificateur ainsi qu'à une clé de modification, de manière à permettre au dispositif électronique utilisateur, lorsqu'il a préalablement stocké l'ensemble d'attributs certifié ainsi que la clé de modification, de modifier l'ensemble d'attributs en effaçant des attributs autres que les attributs (BIRTH_D, CITY) requis pour l'accès anonyme audit service, et de déterminer, à l'aide de la clé de modification, la signature de l'ensemble modifié,
- un dispositif électronique vérifieur (VERIF_PC) agencé pour recevoir du dispositif électronique utilisateur un ensemble certifié d'attributs (BIRTH_D, CITY), et pour contrôler que la signature électronique de l'ensemble reçu correspond à une signature valide d'un dispositif électronique certificateur (CERT_SRV).
16. Programme d'ordinateur agencé pour mettre en œuvre le procédé selon la revendication 1 lorsqu'il est exécuté par un processeur.
17. Support de stockage non transitoire lisible par ordinateur, stockant un programme selon la revendication 16.
PCT/FR2012/052780 2011-12-15 2012-12-03 Accreditations anonymes Ceased WO2013088024A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1161737A FR2984647A1 (fr) 2011-12-15 2011-12-15 Accreditations anonymes
FR1161737 2011-12-15

Publications (1)

Publication Number Publication Date
WO2013088024A1 true WO2013088024A1 (fr) 2013-06-20

Family

ID=47505194

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2012/052780 Ceased WO2013088024A1 (fr) 2011-12-15 2012-12-03 Accreditations anonymes

Country Status (2)

Country Link
FR (1) FR2984647A1 (fr)
WO (1) WO2013088024A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114444125A (zh) * 2022-02-11 2022-05-06 浪潮云信息技术股份公司 一种数字身份管理方法及装置
CN116015673A (zh) * 2022-12-15 2023-04-25 福州大学 基于受限可净化签名的电子病历安全共享方法及系统

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
BEZZI ET AL.: "Privacy and Identity Management for Life", 11 September 2009, SPRINGER, article CAMEISCH J. AND NEVEN G.: "Saving On-Line Privacy", XP009162615 *
GIUSEPPE ATENIESE ET AL: "Sanitizable Signatures", 1 January 2005, COMPUTER SECURITY - ESORICS 2005 LECTURE NOTES IN COMPUTER SCIENCE;;LNCS, SPRINGER, BERLIN, DE, PAGE(S) 159 - 177, ISBN: 978-3-540-28963-0, XP019019069 *
HUGO KRAWCZYK; TAL RABIN, CHAMELEON HASHING AND SIGNATURES, October 1997 (1997-10-01)
MAREK KLONOWSKI ET AL: "Extended Sanitizable Signatures", 1 January 2006, INFORMATION SECURITY AND CRYPTOLOGY 4296/2006; ICISC 2006 LECTURE NOTES IN COMPUTER SCIENCE;;LNCS, SPRINGER, BERLIN, DE, PAGE(S) 343 - 355, ISBN: 978-3-540-49112-5, XP019051336 *
MIYAZAKI K ET AL: "Invisibly sanitizable digital signature scheme", IEICE TRANSACTIONS ON FUNDAMENTALS OF ELECTRONICS,COMMUNICATIONS AND COMPUTER SCIENCES, ENGINEERING SCIENCES SOCIETY, TOKYO, JP, vol. E91A, no. 1, 1 January 2008 (2008-01-01), pages 392 - 402, XP001510014, ISSN: 0916-8508, DOI: 10.1093/IETFEC/E91-A.1.392 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114444125A (zh) * 2022-02-11 2022-05-06 浪潮云信息技术股份公司 一种数字身份管理方法及装置
CN116015673A (zh) * 2022-12-15 2023-04-25 福州大学 基于受限可净化签名的电子病历安全共享方法及系统

Also Published As

Publication number Publication date
FR2984647A1 (fr) 2013-06-21

Similar Documents

Publication Publication Date Title
EP3251046B1 (fr) Systèmes et procédés pour la gestion d'engagements en réseau d'entités sécurisées
EP3547270B1 (fr) Procédé de vérification d'une authentification biométrique
EP2656538B1 (fr) Accès anonyme a un service au moyen de certificats agrégés
EP2441207B1 (fr) Procédé cryptographique d'authentification anonyme et d'identification séparée d'un utilisateur
FR3041195A1 (fr) Procede d'acces a un service en ligne au moyen d'un microcircuit securise et de jetons de securite restreignant l'utilisation de ces jetons a leur detenteur legitime
EP3731116B1 (fr) Procédé d'authentification d'un document d'identité d'un individu et d'authentification dudit individu
EP1459479A2 (fr) Systeme cryptographique de signature de groupe
WO2011117486A1 (fr) Infrastructure non hierarchique de gestion de bi-cles de securite de personnes physiques
EP3731117B1 (fr) Procedes d'enrolement de donnees d'un document d'identite d'un individu et d'authentification d'un document d'identite
FR3098947A1 (fr) Procédé de traitement d’une transaction émise depuis une entité de preuve
EP1004101A1 (fr) Terminal et systeme pour la mise en oeuvre de transactions electroniques securisees
CA2888103C (fr) Procede de signature electronique a signature ephemere
EP2742645B1 (fr) Procédé de gestion et de contrôle de données de différents domaines d'identité organisés en ensemble structure
WO2007012583A1 (fr) Procede de controle de transactions securisees mettant en oeuvre un dispositif physique unique, dispositif physique, systeme, et programme d'ordinateur correspondants
FR3035248A1 (fr) Systeme-sur-puce a fonctionnement securise et ses utilisations
FR2984647A1 (fr) Accreditations anonymes
EP2005379B1 (fr) Sécurisation de transaction électroniques sur un réseau ouvert
WO2016135419A1 (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
FR2829645A1 (fr) Protocole d'authentification a verification d'integrite de memoire
WO2022096841A1 (fr) Procede d'authentification securise par le decouplage structurel des identifiants personnels et de services
EP3371760A1 (fr) Procédé de verification d'identité lors d'une virtualisation
WO2017005644A1 (fr) Procédé et système de contrôle d'accès à un service via un média mobile sans intermediaire de confiance
FR2898423A1 (fr) Procede securise de configuration d'un dispositif de generation de signature electronique.
FR3007929A1 (fr) Procede d'authentification d'un utilisateur d'un terminal mobile
EP3284209A1 (fr) Procédés de génération et de vérification d'une clé de sécurité d'une unité monétaire virtuelle

Legal Events

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

Ref document number: 12810329

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12810329

Country of ref document: EP

Kind code of ref document: A1