• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    The present invention relates to a method for controlling the identity of a user (U), comprising the following steps implemented by an identity control device (3): • reading in a public database (4) d any confidential protected data previously generated by an identity evidencing device (1) from a user identity element (U) and from at least one random data item specific to the user (U), • verification (120) of compliance with a condition on the confidential protected data found in the public database (4), • implementation of predetermined processing for the user (U) only if the condition is respected.
    公开号:FR3058243A1
    申请号:FR1752724
    申请日:2017-03-30
    公开日:2018-05-04
    发明作者:Herve Chabanne；Thomas CHENEVIER；Laurent Lambert；Olivier Clemot
    申请人:Safran Identity and Security SAS；
    IPC主号:
    专利说明:

    FIELD OF THE INVENTION
    The present invention relates to a method of verifying the identity of a user.
    STATE OF THE ART
    In recent years, databases called “blockchains” have appeared.
    A blockchain type database is distributed among several storage nodes on a network. The storage nodes are configured to validate data written in the database by implementing a method of finding consensus between the storage nodes. Such a method is for example the known method of "proof by work" ("proof of work" in English). The content of the database is thus protected against falsification despite its distributed nature.
    The most famous blockchain database is the one used in the Bitcoin® electronic money transaction system. The Bitcoin® system database contains a history of all past transactions between accounts of users of the system. This eliminates the need to use a centralized entity such as a bank to authenticate transactions.
    However, it has been proposed to use a blockchain database for purposes other than the simple transaction of electronic money.
    In particular, the Massachusetts Institute of Technology (MIT) has proposed using the Bitcoin® system blockchain database to prove that a person has an MIT diploma.
    To this end, an MIT server generates an electronic MIT diploma from at least one element of a person's identity, for example the person's name, first name and date of birth.
    Transaction data indicating that MIT has transferred a certain amount of Bitcoins to the person are stored in the public database of the Bitcoin® system. The transaction data also includes an electronic diploma hash, to indicate that the transaction represents the issuance of an MIT diploma to that person. The processing for generating the hash of the MIT diploma from the identity element is made available to the public.
    Indeed, to verify if a given person has indeed graduated from MIT, a potential employer uses this processing to generate a hash of electronic witness diploma, and checks, in the database of the Bitcoin® system, if there is a hash electronic diploma not only contained in a transaction issued by MIT but also identical to the witness electronic diploma generated by the third party. If yes, the candidate is a graduate of MIT, otherwise it is not.
    For example, the processing in question can take as input the or each element of identity in the form of respective character strings. The processing which is done here in a dematerialized way corresponds to a filling of personalized fields in a generic diploma model.
    It is understood that the graduate spontaneously gives his identity to the employer so that the latter can carry out the verification described above.
    However, some third parties may come to the conclusion that the person concerned is indeed a graduate of MIT, without the person's authorization.
    Indeed, an acquaintance of the person is likely to know the elements of identity concerning him (at least his name and first name). This knowledge can thus implement the same steps as those implemented by the employer: use the processing made available to the public to generate a hash of electronic witness certificate and find out if the hash is contained in an issued transaction by MIT.
    This poses a privacy concern, as an MIT graduate may well not want anyone to have access to such private information.
    STATEMENT OF THE INVENTION
    An object of the invention is to control the identity of a user, by means of a public database while solving the confidentiality problem encountered in the solution proposed by MIT.
    It is therefore proposed, according to a first aspect of the invention, a method of controlling the identity of a user, comprising the following steps implemented by an identity control device:
    • reading in a public database of any data protected in confidentiality previously generated by an identity attesting device from an element of identity of a user and from at least one datum of its own hazard to the user, • verification of compliance with a condition on data protected in confidentiality found in the public database, • implementation of a predetermined processing for the user only if the condition is respected.
    As the database used is public, data protected in confidentiality can be read by any third party. However, data protected in confidentiality depends not only on at least one element of a user's identity but also on the random data.
    A third party who knows the user cannot know whether the predetermined processing is being carried out or not. Indeed, even if this third party knows the elements of the user's identity used by the identity attesting device to generate the data protected in confidentiality. He must indeed also know the hazard data.
    The method according to the first aspect of the invention may further comprise the following characteristics taken alone or in combination when technically possible.
    In one embodiment, the method according to the first aspect can comprise steps of:
    • obtaining, by the identity control device, second data protected in confidentiality depending on the identity element and the random data, in which the second data protected in confidentiality are received from a client device belonging to the user or are generated by the identity control device from the identity element and the random data, • implementation of the predetermined processing only if the identity control device finds, in the public database, data protected in confidentiality both generated by the identity attesting device and equal to the second data protected in confidentiality obtained.
    In another embodiment, the method according to the first aspect can comprise steps of:
    • obtaining, by the identity control device, of proof data, the proof data having been previously generated by a client device belonging to the user from the element of identity of the user and the user-specific hazard data, • implementation of predetermined processing only the data protected in confidentiality found and the proof data are linked by a predetermined mathematical relationship.
    Evidence data can be received by the identity control device via a secure channel established directly between the client device and the identity control device.
    Alternately,
    • the proof data are obtained by reading the proof data in the public database, • the predetermined processing is implemented only if the following conditions are met:
    o the evidence data read is associated, in the public database, with the data protected in confidentiality previously generated by the identity attesting device, o the data protected in confidentiality found and the proof data associated with the data protected in confidentiality found are linked by a predetermined mathematical relationship.
    The data protected in confidentiality may have been generated by applying a predetermined hash function H to data x 0 , ..., x n , where:
    • n is an integer greater than or equal to 2, • at least one of the x t is a hazard data specific to the user, and each other x t is an element of identity of the user, and in which evidence includes:
    • a data c calculated by the formula: c = h (H (A 0 , ..., 4 n )) where h is a predetermined function, and A 0 , ..., A n are n data drawn at random, • n proof data f 0 , calculated by applying formulas
    Vf e [Ο, η] fi = Ai + cXi in which case the predetermined mathematical relation can be as follows:
    f H (f 0 ..... fn)
    The data protected in confidentiality generated by the identity attesting device can be associated in the public database with first transaction data indicating that the identity attesting device has transferred a predetermined amount of electronic money to a beneficiary.
    The beneficiary can be the user. In this case, the proof data can be associated in the public database with second transaction data indicating that the user has transferred to the identity control device the predetermined amount received from the identity attesting device.
    The predetermined processing can be, include or trigger a predetermined service to be provided to the user, the method further comprising generation and storage in the public database, of confirmation data indicating that the service has been provided to the user .
    The generated confirmation data can be associated in the public database with third transaction data indicating that a service provider device having provided the service to the user has transferred the predetermined amount to the identity attesting device.
    The method according to the first aspect may further comprise steps of • after the predetermined processing has been implemented by the identity control device, generation by the identity attesting device of new data protected in confidentiality from the identity element of the user and of at least one new random data item specific to the user, • storage of the new data protected in confidentiality in the public database so that a new implementation of the step Verification uses new confidential data in place of confidential data.
    The public database is, for example, a distributed blockchain type database.
    The generation of data protected in confidentiality may include a cryptographic hash applied to the element of identity and to the random data.
    Data protected in confidentiality can be obtained by applying the formula:
    n fl · ”i = 0 where:
    • n is an integer greater than or equal to 2, • at least one of the x t is a hazard data specific to the user, and each other x t is an element of user identity, • Gi are predetermined elements of a finite group, for example elliptical curve points or elements of a cyclic group.
    Data protected in confidentiality can be digitally signed using a private key specific to the identity attesting device, before being stored in the public database.
    The method can also comprise steps of:
    • electronic signature of the proof data using a private key specific to the user, before their storage in the public database, • access, by the identity control device, to the proof of service data by decryption signed evidence data stored in the public database, using a user-specific public key.
    The predetermined processing can be implemented by the identity control device only if the identity control device does not find, in the public database, revocation data indicating that the user's private key has been revoked by the identity attesting device.
    It is further proposed, according to a second aspect of the invention, a computer program product comprising program code instructions for the execution of the steps of the method according to the first aspect of the invention, when this program is executed. by at least one processor.
    According to a third aspect of the invention, there is also proposed an identity control device for controlling the identity of a user, the identity control device comprising an interface for communication with a public database. and at least one processor configured to:
    • order the reading, in the public database, of any data protected in confidentiality previously generated by an identity attesting device from an element of user identity and from at least one piece of data hazard specific to the user, • verify compliance with a condition on the data protected in confidentiality found, • implement a predetermined processing for the user only if the proof is established.
    According to a fourth aspect of the invention, there is also proposed a system comprising:
    • an identity control device according to the third aspect of the invention, • an identity attesting device configured to generate the data protected in confidentiality and to control the storage of the data protected in confidentiality in the public database.
    According to a fifth aspect of the invention, there is also proposed a client device intended to belong to a user, the client device comprising a communication interface with a public database, and at least one processor configured for:
    • generate proof data from an element of identity of the user and at least one hazard data specific to the user, • order a storage, in a public database, of the evidence to indicate that the evidence has been generated by the client device, and in association with data protected in confidentiality previously generated by an identity attesting device from the same element of identity and d 'same random data, • implementation of predetermined processing only the data protected in confidentiality found and the evidence data are linked by a predetermined mathematical relationship.
    DESCRIPTION OF THE FIGURES
    Other characteristics, objects and advantages of the invention will emerge from the description which follows, which is purely illustrative and not limiting, and which should be read with reference to the appended drawings in which:
    • Figure 1 schematically shows a system for providing a service, according to one embodiment.
    • Figure 2 is a flow diagram of steps of a method of providing a service implemented by the system shown in Figure 1, according to one embodiment.
    In all of the figures, similar elements bear identical references.
    DETAILED DESCRIPTION OF THE INVENTION
    Service delivery system based on an element of identity
    Referring to Figure 1, a service delivery system includes an identity attesting device 1, a client device 2 and an identity control device 3.
    The three devices 1, 2, 3 communicate with each other via at least one R network, for example the Internet network, a cellular network, or a combination of such networks.
    The three devices 1, 2, 3 each have read and write access to a database 4 stored in the network R.
    The database 4 is public, in the sense that it is free to read access not only by the devices 1, 2, 3 in presence but also to any other third-party device. Any third-party device can in particular consult the data written by one of the devices 1,2,3.
    Thus, the identity attesting device 1 has a read and write access account in the database 4. For this purpose, the identity attesting device 1 stores two mutually associated keys: a private key of signature, specific to device 1 and a public signature verification key also specific to device 1. The private key allows device 1 to write signed data in the database; it is intended not to be communicated to third parties. The public key enables device 1 (and any other holder of a database access account 4) to verify that data present in database 4 has been written to it by the device 1.
    The identity control device 3 also has a read and write access account in the database 4. As for the identity witness device 1, the identity control device 3 stores a key public and a private key mutually associated and specific to it.
    The database 4 is distributed or decentralized in the network R, that is to say that it is stored by a plurality of nodes of the network R with which the devices 1, 2, 3 can communicate.
    The database 4 is a “blockchain” type database. In the present text, a “blockchain” type database is defined as a database stored by a plurality of storage nodes configured to validate data written to the database by the implementation of a method of finding consensus between storage nodes. Such a method is for example the known method of "proof by work" ("proof of work" in English). The content of database 4 is thus protected against falsification, despite its distributed / decentralized nature.
    In the following, we will take the example of a database 4 conforming to that used by the Bitcoin® transaction system. Thus, data representative of a transaction can be stored in the database 4, from one of the devices 1, 2, 3 to another of these devices 1, 2, 3, of a certain amount in Bitcoins.
    Each of the three devices 1, 2, 3 comprises at least one processor configured to carry out data calculations and a communication interface for communicating with the other devices and the database 4.
    The main function performed by the identity attesting device 1 is to certify whether a user is approved or not. The identity attesting device 1 could thus be used in France by the National Agency for Secure Titles (ANTS) or the Imprimerie Nationale, these bodies having the purpose of meeting such a need. The device 1 can however be managed by a private company, for example an airline company (example which will be developed in the following).
    The main function of the identity control device 3 is, as its name suggests, to control the identity of a user.
    The control device is configured to implement or not a predetermined processing on behalf of a user, according to the result of an identity check that it has implemented on this user.
    For example, the control device is configured to provide a predetermined service to a user approved by the device 1. In this case, the predetermined processing implemented or not depending on the result of a check of the identity of a user is a supply or not of this service to this user. For example, the identity control device 3 is a device for managing passenger accounts of the aforementioned airline. This device 3 is then for example adapted to allocate or withdraw travel points to a given traveler, and to assign travel advantages to him.
    Alternatively, the control device 3 is adapted to communicate with a separate service provider device. In this case, the predetermined processing can comprise the sending to the service provider device of a message indicating whether a user having just been controlled by the control device has the right or not to be provided with a service by the provider device on duty.
    The predetermined processing may alternatively or additionally include an increase in the level of reputation of a user approved by the identity attesting device 1 with a third party organization. This notion of reputation for example used by banks or insurers to assess the profile of their customers. This increase can typically be made by incrementing a data representative of a reputation level, implemented by the control device 3 and / or by the supplier device.
    The client device 2 is also a device intended to be manipulated by a user U likely to request to be rendered a service by the identity control device 3. The client device 2 is for example a smartphone or a portable computer.
    Method of providing a service based on the identity of a user ίο
    In what follows, it will be considered, without limitation, that the control device 3 is capable of rendering a service to an authorized user (it is in other words a service provider device).
    It is further assumed in the following that is stored by the client device 2 a management application configured to establish a communication channel with the device 1 and a communication channel with the device 3 (for example via the network R) . Such an application can be downloaded on the initiative of the user U.
    The two communication channels are independent of the database 4, that is to say that data or messages which pass through any of these channels are not written to the database 4.
    In a step 100, the user U is enrolled with the identity attesting device
    1.
    According to a first variant of the enrollment step 100, the user U contacts an airline counter and orally provides at least one element of identity relating to him.
    According to a second variant of the enrollment step 100, the application displays a message on a screen of the client device 2 inviting the user U to enter at least one element of identity relating to him. The or each element of identity entered by the user U in his client device 2 is transmitted to the identity attesting device 1 via the communication channel established by the application between the devices 1 and 2.
    One or more elements of user identity U can thus be supplied to the identity attesting device 1.
    An identity element of user U can be a civil status element of user U (surname, first name, date of birth, place of birth, etc.). An element of identity can also be information indicating whether the user is of legal age or not. An element of identity can more generally be any personal information of the user U (for example: passport number, identity card number, etc.).
    It is easy to understand that an element of identity is more or less carrying information. It is therefore possible to define sets of elements of identities to be processed, which are associated with respective confidentiality levels:
    • level 1 identity elements: majority of user U • level 2 identity elements: level 1 identity elements + user name U • level 3 identity elements: elements of level 2 identities + user address U.
    u
    Furthermore, the enrollment includes the creation of a read and write access account in the database 4 for the user U. The creation of the account includes the allocation to the user U of two mutually associated keys having the same functions as those available to devices 1 and 3: a private signature key, specific to user U and a public signature verification key also specific to user U.
    Typically, the application itself generates the key pair of the user U and the public key is communicated in a privileged manner to the identity attesting device 1.
    The two keys of the user U are memorized by in a memory of the client device 2 on command of the application.
    In what follows, any data written in the database 4 at the request of an entity holding a database access account 4 is implicitly signed before being written using the private key specific to this entity. In addition, any signed data read in the database 4 by a third party holder of a database access account 4 is implicitly verified by means of the public key specific to the entity, so as to obtain the data originally provided by the entity.
    At least one hazard data item associated with the identity element supplied by the user U is also generated (step 102).
    This hazard data can be generated by the identity attesting device 1 as illustrated in FIG. 2, in which case the hazard data is transmitted from the identity attesting device 1 to the client device 2 (step 104). Alternatively, the hazard data can be generated by the client device 2 (in which case the client device 2 transmits the hazard data to the identity attesting device 1).
    In the following, x 0 denotes the hazard data, and x r to x n are n elements of identity supplied to the identity attesting device 1, n being greater than or equal to 1. The set of elements of identities x r to x n can for example be one or the other of the identity sets of level 1, 2 or 3 defined above.
    The identity attesting device 1 generates data protected in confidentiality from at least one element of identity and from the hazard data (step 106). "Protected in confidentiality" means that the element of identity and the hazard data do not appear in clear in the data protected in confidentiality.
    In general, the generation 106 of data protected in confidentiality can be seen as the application of a predetermined function H to the identity elements and to the random data. Data protected in confidentiality can thus be written: Η (χ 0 , ..., χ η ).
    In the following, an embodiment will be detailed in which the data protected in confidentiality is hashed data: in other words, the predetermined function H is a hash function. Hashed data is also called "fingerprint" or "hash" in the literature.
    The hash function H has several advantages. The value of the result of its application cannot be predetermined. Furthermore, the function H is difficult to reverse so that it is almost impossible to trace the antecedents of the function H from the hashed data H (x 0 , ..., x n ), or to find two antecedents having the same image A particular embodiment of the invention is developed below in which the hashed data is obtained by application of the following formula:
    not
    H (x 0 , ..., x n ) = J ”[Gf 1 i = 0 where the terms G; are predetermined elements of a finite group, for example points of elliptical curve or elements of a cyclic group. The terms G ; are also known to the client device 2 and to the identity control device 3.
    The identity attesting device 1 controls the storage of the hashed data H (x 0 , ..., x n ) in the database 4 in a manner suitable for indicating to any third party that the hashed data has been generated by the identity attesting device 1 (step 108). This indication materializes the fact that the hashed data was generated on the basis of a user (here U) approved by the identity attesting device 1. As will be seen below, a predetermined processing will be implemented for the benefit of a user only if this user turns out to have been approved by the identity attesting device 1. For example, an authorized user may be rendered a service by the identity checking device 3 (or a device providing service separate from the identity control device 3) while an unauthorized user will not be able to access such a service.
    When an electronic money management system such as Bitcoin® is used, such an indication can be obtained by means of a transaction of a certain amount of electronic money from the identity attesting device 1 for the benefit of the client device 2.
    The identity attesting device 1 generates, for example, first transaction data T (K, 1 => 2) suitable for indicating that the identity attesting device 1 transfers to the user U a predetermined amount K of electronic money, by example K Bitcoins. The user U beneficiary of the transaction is identified by his public key, which was provided to him when his account for accessing the database 4 was created.
    The identity attesting device 1 then controls the storage 108, in the database 4, of the first transaction data and of the hashed data. The first transaction data is associated with the public key of the user U in the database 4, so as to indicate to a third party accessing the database 4 that this user U is the beneficiary of the K Bitcoins transferred by the identity attesting device 1.
    This association is for example an inclusion of the hashed data H (x 0 , in the first transaction data. When the Bitcoin® system is used, the first transaction data includes an OP_RETURN field which can be used to store the hashed data.
    Later, the user U wishes to access the service rendered by the identity control device 3. To this end, the application generates a service request (step 114), and orders the sending of the request generated by the client device 2 of the user U to the identity control device 3, via a channel previously established between the devices 2 and 3 (step 116).
    On receipt of this request, the identity control device 3 reads access to the database 4, and searches there for any hashed data previously generated by the identity attesting device 1 from an element of identity of user U and from at least one hazard data specific to user U.
    If such hash data is found in database 4, the identity checker checks whether a condition on the hash data is met.
    If the condition is met, the identity control device 3 provides the requested service to the client device 2 (step 122). The identity control device 3 indeed deduces from hashed data that the requesting user has been previously approved by the identity attesting device 1.
    If the condition is not fulfilled, the identity control device 3 does not provide the service requested to the client device 2. In this case, the provider device 3 deduces indeed from the absence of hashed data on the basis of an element of identity of the requesting user that this requesting user U has not been approved by the identity attesting device 1.
    In the case of user U, the service is well rendered since hashed data H (x 0 , ..., x n ) has indeed been generated by the identity attesting device 1 and then stored at the latter's request in the database 4.
    In other words, the identity control device 3 does a service to a requesting user only if this user has been approved by the identity attesting device 1. It can be noted that the identity control device 3 did not have to communicate directly with the identity attesting device 1 to decide whether the service is to be provided or not to the requesting user; he only had to inspect the content of the database 4. One advantage of this solution is its flexibility of use: the identity control device 3 can take a decision relating to the service request formulated even when the identity attesting device is not available (switched off, not connected to the network, or simply faulty).
    In addition, the use of the “blockchain” type database 4 allows very simple deployment of the process. The devices 1, 2, 3 need only a minimum configuration (in particular the creation of access accounts to the database 4), the security of the process in terms of protection against falsifications being ensured by the base 4. The use of the database of a transaction system such as Bitcoin® or equivalent is particularly easy to implement.
    In addition, no identity element was directly written in clear in the database 4. Only the hashed data is stored in the database 4. However, since the hashed data depends not only on at least one element of identity but also of random data, it is impossible for a third party - knowing the element of identity of user U - to conclude that user U has been approved by the device attesting to identity 1 without also knowing the element of the hazard, by simple access to the database 4 which is public.
    First embodiment
    FIG. 2 illustrates a first embodiment, in which the client device 2 detects that the database 4 contains the first transaction data indicating that K Bitcoins have been transferred to the user U.
    Following this detection, the client device 2 generates proof data which depend on the identity element of the user U and on the random data x 0 specific to the user U (step 110).
    For example, the proof data includes a first proof data c and n proof data f 0 , which are calculated as follows:
    / nc = h (H (A 0 ..... AJ) = / i i = 0 where h is a predetermined hash function (for example different from the function H), and 4 0 , ..., A n are n data drawn at random; and
    Vi e JO, n] f = Ai + cXi
    The client device 2 controls the storage, in the database 4, of the proof data c, f 0 , so as to indicate that the proof data have been generated by the client device 2 (step 112).
    The data c, f 0 , of proof are moreover associated, in the database 4, with the hashed data H (x 0 , ..., x n ) previously generated by the identity attesting device 1, so as to indicate that the proof data and the associated hashed data were generated from the same elements of identity x-ι, ..., Χη and from the same random data x 0 (specific to user U).
    When an electronic money management system such as Bitcoin® is used, such an indication can be obtained by means of at least one transaction to the identity attesting device 1 covering the amount of electronic money that the user U has received from the identity attesting device 1. For this purpose, the client device 2 generates second transaction data T (K, 2 => 3) indicating that the requesting user U transfers the amount to the identity checking device 3 predetermined K received from the identity attesting device 1. The client device 2 then controls the storage 112, in the database 4, of the second transaction data and of the proof data. The second transaction data are associated in the database 4 with the public key of the identity control device 3, so as to indicate that the identity control device 3 is the beneficiary of the K Bitcoins transferred by the client device 2.
    This association is for example an inclusion of the proof data in the second transaction data. When the Bitcoin® system is used, the second transaction data includes an OP_RETURN field which can be used to store the proof data.
    The evidence may be too large to be stored in a single OP_RETURN field. In this case, the client device 2 generates and then controls the storage in the database 4 of several second transaction data, the sum of the amounts of the second transactions being equal to K.
    The preceding steps 110, 112 are implemented before the client device 2 sends the service request to the identity control device 3. For example, the client device 2 sends the service request immediately after having confirmation that the second transaction data has been stored in the database 4.
    The supplier device 3 detects that the database 4 contains the second transaction data, indicating that K Bitcoins have been transferred to it by the client device 2.
    This detection is for example implemented by the supplier device 3 in response to the reception of the service request sent by the client device 2 during step 114.
    The identity control device 3 reads the database 4 and downloads the proof data associated with the second transaction data designating it as the beneficiary of K Bitcoins (step 118). It suffices for this to read the content of the OP_RETURN field of the second transaction data T (K, 2 => 3).
    The identity control device 3 therefore has knowledge of the proof data c, f 0 at this stage. Furthermore, as indicated above, the identity control device 3 also has knowledge of the function H. It is also assuming that the identity control device 3 knows the function h.
    The identity control device 3 checks whether two conditions are cumulatively fulfilled (step 120): a first condition and a second condition.
    The first condition to be fulfilled is the existence, in the database 4, of proof data which have been generated on the one hand by the client device 2 and which are on the other hand associated with data hashed by the attesting device identity 1.
    If the Bitcoin® system is used, the identity control device 3 simply determines the source of the K bitcoins it has received. If there is, in the database 4, transaction data indicative of the transfer of the K bitcoins from the identity attesting device 1 to the client device 2, then the identity checking device 3 reads the content of the OP_RETURN field of said transaction data and considers it to be hashed data generated by the identity attesting device 1.
    In the case of user U, the K bitcoins transferred by the client device 2 to the identity control device 3 in the second transaction data T (K, 2 => 3) had been previously transferred by the identity attesting device 1 to the client device 2 in the first transaction data T (K, 1 => 2). The access provider device 3 thus reads the content of the OP_RETURN field of the first transaction data to obtain the hashed data.
    At this stage, the identity control device knows the evidence data but also the hashed data with which the evidence data is associated.
    The second condition to be fulfilled is that the hash data possibly found and the proof data associated with the hash data possibly found must be linked by a predetermined mathematical relation.
    The predetermined mathematical relationship is as follows:
    / H (fofn) (H (x 0 ..... x n )) 7 C
    For example, in the case where H (x 0 , ..., x n ) = ΠΡ = ο G i Xi this predetermined mathematical relation becomes:
    nF., c / 'j V (nr = o <Y') 9
    The identity control device 3 provides the service requested by the client device 2 only if the two conditions are cumulatively fulfilled (step 122).
    If the two conditions are not cumulatively fulfilled, the identity control device 3 does not provide the service requested by the client device 2.
    An advantage of this first embodiment is that the identity control device 3 can determine whether or not a user U has been approved by the identity attesting device 1, without having to know the values of the terms χ έ (elements of identity and random data). The supplier device 3 has in fact used only the hashed data and the proof data stored in the database 4.
    Of course, other evidence data and other mathematical relationships than those presented above can be used to condition the supply of the service by the device 3, for example those described in the document "Rethinking Public Key Infrastructures and Digital Certificates : Building in Privacy ”, by Stefan Brands.
    Second embodiment
    In a second embodiment not illustrated, simpler to implement than the first embodiment, the values of the terms χ έ (identity elements and random data) are supplied to the identity control device 3 by the requesting user U. The values of the terms χ έ are for example transmitted by the client device 2 to the identity control device 3.
    The identity control device 3 generates hashed data from the identity element of the requesting user U and the random data specific to the requesting user U which have thus been supplied to it. The device 3 uses for this the function H of which it is aware.
    The identity control device 3 also reads access to the database 4, and also checks whether the database 4 contains hashed data both indicated as having been generated by the identity attesting device 1 and equal to the hashed data generated by the identity control device 3.
    If so, the identity control device 3 provides the service requested in step 122. Otherwise, the identity control device 3 rejects the service request.
    Steps after the provision of the service
    After the service has been rendered by the identity control device 3 to the requesting user U during step 122, the identity control device 3 generates confirmation data indicating that the service has been provided to the requesting user U (step 124).
    These confirmation data are stored in the database 4 on command of the identity control device 3 (step 126).
    When an electronic money management system such as Bitcoin® is used, the confirmation data generated by the identity control device 3 are associated in the database 4 with third transaction data T (K, 3 = > 1) indicating that the access provider device 3 has transferred to the identity attesting device 1 the amount K received from the client device 2.
    Thus, the identity attesting device 1 is credited with the amount K that it had previously spent.
    The third transaction data is generated by the identity control device 3 and is similar to the first and second transaction data. When the Bitcoin® system is used, the third transaction data includes an OP_RETURN field which can be used to store the confirmation data.
    The identity attesting device 1 can thus be informed of the fact that the identity checking device 3 has rendered a service to a user U which it has previously approved, without however communicating directly with the identity checking device 3 since it is sufficient for the identity attesting device 1 to read (step 128) the confirmation data contained in the database 4 which are associated with the third transaction data, and to decrypt the signed confirmation data by means of a public key specific to the identity control device 3.
    Preferably, the hazard element is for single use. Thus, even if a malicious third party were to learn the element of hazard specific to user U, he could not use it several times with the identity control device 3.
    For example, after the service has been rendered by the identity control device 3 to the user U, the identity attesting device 1 randomly draws new random data specific to the user U (step 102) , then generates new hashed data from the identity element of the requesting user U and from the new random data (step 106), and controls the storage of the new hashed data in the database 4 so that a new implementation of the proofing step uses the new hashed data instead of the previously hashed data.
    It can also be arranged to assign to user U a new pair of public and private keys after the service has been rendered by the identity control device 3 to user U. The new pair of keys can be generated by the application executed by the client device 2 at the request of the identity attesting device 1, or else be generated by the identity attesting device 1 and then transmitted by the latter to the client device 2 via the network R.
    As indicated above, the client device 2 is intended to be handled by the user U. In the event of theft of the client device 2, an unauthorized user U could attempt to obtain access to the service rendered by the device 3 by pass for the real owner of the client device 2. Also, it is advantageous to store revocation data in the database 4 indicating that the requesting user U has been revoked by the identity attesting device 1. This storage is typically controlled by the identity attesting device 1.
    Thus, the service will be provided by the identity control device 3 only if the identity control device 3 does not find, in the database 4, revocation data indicating that the private key of the requesting user U has been revoked by the identity attesting device 1.
    The revocation data are for example stored in the database 4 in the same format as the hashed data. In the case where the Bitcoin® system is used, the identity attesting device 1 generates fourth transaction data indicating the transfer of K bitcoins to the user to be revoked (here U). The OP_RETURN field of the fourth transaction data contains the revocation data. The revocation data are for example a predetermined character string, for example “REVOKED”. As previously indicated, the identity control device 3 reads the hashed data from the database 4 before providing the service requested by the requesting user U.
    In addition to the conditions set out in the first embodiment and the second embodiment described above, the identity control device 3 checks whether the data in the OP_RETURN field of transaction data transferring to it K bitcoins contains the revocation data. If yes, then the service is not provided.
    The method described above is of course not limited to an electronic money transaction management database 4, even less to the Bitcoin® system.
    The method is obviously applicable to any type of predetermined processing to be performed or not depending on the identity of the requesting user U, whether by the identity control device 3 itself or by another device with which the identity control device 3 communicates.
    The method advantageously finds application to increase the reputation of a user approved by the identity attesting device 1 with third parties.
    All database access accounts 4 are anonymous in the sense that the real identities of the holders of database access accounts 4 are not known to third parties by simply reading the content of the database. data 4. A third party reading the transaction data T (K, 1 => 2), T (K, 2 => 3) and T (K, 3 => 1) notes that K bitcoins are successively owned by a first account , then by a second account, then by a third account. To read this transaction data, any third party can use the public key associated with each of these accounts. However, the third party does not know the identity of the holder of each of these three accounts. In particular, the third party has absolutely no knowledge that user U is one of these holders.
    However, user U may want to reveal that he is the holder of his account to a third party, with whom he wishes to increase his reputation, for example a bank.
    In addition, user U can hold different accounts. The user U is for example holder of a first account used for the implementation of the above process involving the devices 1 and 3, and holder of a second account used for the implementation of the same process, but involving a identity attesting device different from device 1 and a service provider device different from device 3. In this case, user U, can reveal to the third party with whom he wishes to increase his reputation only that he is the holder of one of the first and second accounts, in which case it gives this third party only fragmentary information concerning it. Alternatively, the user can reveal that he is the holder of the first and second accounts.
    Furthermore, we have previously seen that the devices 1, 2 and 3 each have an access account to the database 4. In particular, it is provided in the embodiment illustrated in FIG. 2 that a user U accesses to the content of the base 4 via an account that he will have created on his own initiative through the client device 2.
    In another embodiment, the devices 1 and 3 certainly each have such an access account, but no access account to the public database 4 needs to be created by the user U. In this embodiment, the identity attesting device performs a transaction to a predetermined third-party account, specially created for the user U by the identity attesting device 1, or to itself.
    The identity attesting device 1 then transmits to the client device 2, via a secure channel, a message containing location data making it possible to locate in the public database 4 the data protected in confidentiality which have been stored there on the order of the device identity certificate 1. This location data can be a reference to the transaction operated by the device 1, for example a blockchain ID. This location data can then be transmitted by the client device 2 to the identity control device 3 to allow the control device 3 to locate the data protected in confidentiality previously stored on the order of the identity attesting device 1.
    权利要求:
    Claims (21)
    [1" id="c-fr-0001]
    1. Method for controlling the identity of a user (U), comprising the following steps implemented by an identity control device (3):
    • reading in a public database (4) of any data protected in confidentiality previously generated by an identity attesting device (1) from an element of identity of a user (U) and from '' at least one hazard data specific to the user (U), • verification (120) of compliance with a condition on the data protected in confidentiality found in the public database (4), • implementation of '' predetermined processing for the user (U) only if the condition is met.
    [2" id="c-fr-0002]
    2. Method according to claim 1, further comprising the steps of:
    • obtaining, by the identity control device (3), second data protected in confidentiality depending on the identity element and the random data, in which the second data protected in confidentiality are received from a client device (2) belonging to the user (U) or are generated by the identity control device (3) from the identity element and the random data, • processing implementation predetermined only if the identity control device (3) finds, in the public database (4), data protected in confidentiality both generated by the identity attesting device (1) and equal to the second protected data in confidentiality obtained.
    [3" id="c-fr-0003]
    3. Method according to claim 1, comprising steps of:
    • obtaining, by the identity control device (3), of proof data, the proof data having been previously generated (110) by a client device (2) belonging to the user (U) from element of identity of the user (U) and of the hazard data specific to the user (U), • implementation of the predetermined processing only the data protected in confidentiality found and the evidence data are linked by a predetermined mathematical relationship.
    [4" id="c-fr-0004]
    4. Method according to claim 3, in which the proof data is received by the identity control device (3) via a secure channel established directly between the client device (2) and the identity control device (3 ).
    [5" id="c-fr-0005]
    5. Method according to claim 3, in which:
    • the proof data are obtained by reading the proof data in the public database (4), • the predetermined processing is implemented only if the following conditions are met:
    o the evidence data read is associated, in the public database (4), with the data protected in confidentiality previously generated by the identity attesting device (1), o the data protected in confidentiality found and the associated proof data to the data protected in confidentiality found are linked by a predetermined mathematical relation.
    [6" id="c-fr-0006]
    6. Method according to one of claims 3 to 5, in which the data protected in confidentiality were generated by application of a predetermined hash function H to data x 0 , ..., x n , where:
    • n is an integer greater than or equal to 2, • at least one of x t is a hazard data specific to the user (U), and each other Xi is an element of user identity ( U), and in which the evidence includes:
    • a data c calculated by the formula: c = h (H (A 0 , ..., 4 n )) where h is a predetermined function, and A 0 , ..., A n are n data drawn at random, • n proof data f 0 , calculated by applying formulas
    Vi e [Ο, η] fi = Ai + cXi the predetermined mathematical relation being further f H (f 0 ..... fn)
    [7" id="c-fr-0007]
    7. Method according to one of the preceding claims, in which the data protected in confidentiality generated by the identity attesting device (1) are associated in the public database (4) with first transaction data indicating that the device identity certificate (1) has transferred a predetermined amount of electronic money to a beneficiary.
    [8" id="c-fr-0008]
    8. Method according to claim 7 in its dependence on one of claims 3 to 6, in which:
    • the beneficiary is the user (U), • the proof data are associated in the public database (4) with second transaction data indicating that the user (U) has transferred to the identity control device (3) the predetermined amount received from the identity attesting device (1).
    [9" id="c-fr-0009]
    9. Method according to one of the preceding claims, in which the predetermined processing is, comprises or triggers a predetermined service to be provided to the user (U), the method further comprising a generation (124) and storage (126) in the public database (4), confirmation data indicating that the service has been provided to the user (U).
    [10" id="c-fr-0010]
    10. The method of claims 8 and 9 taken in combination, wherein the generated confirmation data is associated in the public database (4) with third transaction data indicating that a service provider device having provided the service to the user (U) has transferred to the identity attesting device (1) the predetermined amount.
    [11" id="c-fr-0011]
    11. Method according to one of the preceding claims, further comprising steps of • after the predetermined processing has been implemented by the identity control device (3), generation (102) by the device attesting to identity (1) of new data protected in confidentiality from the identity element of the user (U) and at least one new datum of hazard specific to the user (U), • storage (108 ) new data protected in confidentiality in the public database (4) so that a new implementation of the verification step (120) uses the new data protected in confidentiality in place of the data protected in confidentiality.
    [12" id="c-fr-0012]
    12. Method according to one of the preceding claims, in which the public database (4) is a distributed database of the blockchain type.
    [13" id="c-fr-0013]
    13. Method according to one of the preceding claims, in which the generation of the data protected in confidentiality comprises a cryptographic hash applied to the element of identity and to the random data.
    [14" id="c-fr-0014]
    14. Method according to one of the preceding claims, in which the data protected in confidentiality are obtained by application of the formula:
    n fl · ”i = 0 where:
    • n is an integer greater than or equal to 2, • at least one of x t is a hazard data specific to the user (U), and each other Xi is an element of user identity ( U), • Gi are predetermined elements of a finite group, for example points of elliptic curve or elements of a cyclic group.
    [15" id="c-fr-0015]
    15. Method according to one of the preceding claims, in which the data protected in confidentiality have been digitally signed by means of a private key specific to the identity attesting device (1), before their storage in the public database ( 4).
    [16" id="c-fr-0016]
    16. Method according to one of the preceding claims, further comprising the steps of:
    • electronic signature of the proof data by means of a private key specific to the user (U), before their storage in the public database (4), • access, by the identity control device (3) , to the proof of service data by deciphering the signed proof data stored in the public database (4), by means of a public key specific to the user (U).
    [17" id="c-fr-0017]
    17. Method according to the preceding claim, wherein the predetermined processing is implemented by the identity control device (3) only if the identity control device (3) is not found in the public database (4), revocation data indicating that the user's private key (U) has been revoked by the identity attesting device (1).
    [18" id="c-fr-0018]
    18. A computer program product comprising program code instructions for executing the steps of the method according to one of the preceding claims, when this program is executed by at least one processor.
    [19" id="c-fr-0019]
    19. Identity control device (3) for controlling the identity of a user (U), the identity control device (3) comprising an interface for communication with a public database (4) and at minus one processor configured to:
    • order the reading, in the public database (4), of any data protected in confidentiality previously generated by an identity attesting device (1) from an element of user identity (U) and from at least one hazard data specific to the user (U), • verify (120) compliance with a condition on the data protected in confidentiality found, • implement a predetermined processing for the user only if proof is established.
    [20" id="c-fr-0020]
    20. System comprising:
    • an identity control device (3) according to the preceding claim, • an identity attesting device (1) configured to generate the data protected in confidentiality and to control the storage of the data protected in confidentiality in the public database ( 4).
    [21" id="c-fr-0021]
    21. Client device (2) intended to belong to a user (U), the client device comprising • a communication interface with a public database (4), • at least one processor configured for:
    o generate proof data from a user identity element (U) and at least one hazard data specific to the user (U), o order a storage (112) , in a public database (4), proof data so as to indicate that the proof data have been generated by the client device (2), and in association with data protected in confidentiality previously generated by a certifying device identity (1) from the same element of identity and the same random data, o implementation of predetermined processing only the data protected in confidentiality found and the proof data are linked by a relationship predetermined math.
    1/2
    类似技术:
    公开号 | 公开日 | 专利标题
    FR3058243A1|2018-05-04|METHOD FOR CONTROLLING IDENTITY OF A USER USING A PUBLIC DATABASE
    EP2819052B1|2018-08-01|Method and server for processing a request for a terminal to access a computer resource
    EP3547203A1|2019-10-02|Method and system for managing access to personal data by means of an intelligent contract
    EP3547202B1|2021-10-20|Method for access to anonymised data
    EP1829280A2|2007-09-05|Secured authentication method for providing services on a data transmission network
    FR2922702A1|2009-04-24|SECURING TELECHARGEABLE COMPUTER FILE DATA ON AN AIRCRAFT BASED ON IDENTITY OF ENTITIES, AUTHENFICATION METHOD, SYSTEM AND AIRCRAFT
    FR2930390A1|2009-10-23|METHOD FOR SECURE DIFFUSION OF DIGITAL DATA TO AN AUTHORIZED THIRD PARTY
    CA2888103C|2020-07-21|Electronic signature method with ephemeral signature
    CA2844762C|2020-07-28|Method for managing and checking data from different identity domains organized into a structured set
    WO2017162930A2|2017-09-28|Adaptive device for biometric authentication using ultrasound, infrared and contrast visible light photographs, without disclosure, via a decentralised computer network
    EP3316549A1|2018-05-02|Method for verifying the identity of a user by means of a public database
    CA2895189C|2021-01-26|Group signature using a pseudonym
    EP3836480A1|2021-06-16|Method and device for determining the possibility of using a cryptographic key for performing a cryptographic operation
    FR2881591A1|2006-08-04|Cryptographic operation e.g. digital certificate request, implementing method, involves performing cryptographic operation on data provided by user, and recording information associated to operation
    EP3863219A1|2021-08-11|Method and device for assessing matching of sets of structured data protected by encryption
    EP3789901A1|2021-03-10|Method for selective authentication of a user of a blockchain with an intelligent contract
    FR2913551A1|2008-09-12|User authenticating method for use in Internet network, involves authenticating authentication server by token and vice versa for each of web pages requested by user, by executing control script e.g. java script, in computer
    EP3063898B1|2017-04-12|Signature with pseudonym for chip card
    FR2898423A1|2007-09-14|Certified electronic signature generating device e.g. chip card, configuring method for e.g. computer, involves updating certificate to user upon reception of denomination and number by certificate producer so as to be used with device
    EP2911083B1|2016-09-28|Method to access data of at least a pyhiscal or moral person or of an object
    WO2021122186A1|2021-06-24|Method and device for anonymous access control to a collaborative anonymization platform
    FR3007929A1|2015-01-02|METHOD FOR AUTHENTICATING A USER OF A MOBILE TERMINAL
    FR3107416A1|2021-08-20|EFFECTIVE RANDOM TOKENIZATION IN A DEMATERIALIZED ENVIRONMENT
    WO2021198606A1|2021-10-07|Method and device for authenticating a user with an application
    FR3049088A1|2017-09-22|METHOD FOR MANAGING DIGITAL IDENTITIES ASSOCIATED WITH AN INDIVIDUAL, AN OBJECT, AN ORGANIZATION, A SERVICE, AN APPLICATION THROUGH A DECENTRALIZED COMPUTER NETWORK
    同族专利:
    公开号 | 公开日
    FR3058292A1|2018-05-04|
    FR3058243B1|2018-11-23|
    US20180122031A1|2018-05-03|
    FR3058292B1|2019-01-25|
    US10817967B2|2020-10-27|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US20160105414A1|2014-10-13|2016-04-14|Morpho|Method for Authenticating a Client Device to a Server Using a Secret Element|
    WO2016128906A1|2015-02-11|2016-08-18|Visa International Service Association|Systems and methods for securely managing biometric data|
    US9767453B2|2012-02-23|2017-09-19|XRomb Inc.|System and method for processing payment during an electronic commerce transaction|
    US9628467B2|2013-03-15|2017-04-18|Aerohive Networks, Inc.|Wireless device authentication and service access|
    US9749297B2|2014-11-12|2017-08-29|Yaron Gvili|Manicoding for communication verification|
    KR101637854B1|2015-10-16|2016-07-08|주식회사 코인플러그|Certificate issuance system and method based on block chain, certificate authentication system and method based on block chain|JP2018516026A|2015-03-20|2018-06-14|リヴェッツ・コーポレーションＲｉｖｅｔｚ Ｃｏｒｐ．|Automatic device integrity authentication using blockchain|
    CN108701276A|2015-10-14|2018-10-23|剑桥区块链有限责任公司|System and method for managing digital identity|
    US10861019B2|2016-03-18|2020-12-08|Visa International Service Association|Location verification during dynamic data transactions|
    US10148649B2|2016-05-18|2018-12-04|Vercrio, Inc.|Automated scalable identity-proofing and authentication process|
    FR3099017B1|2019-07-16|2021-08-06|Idemia Identity & Security France|Process for verifying a transaction in a blockchain-type database|
    法律状态:
    2018-02-19| PLFP| Fee payment|Year of fee payment: 2 |
    2018-05-04| PLSC| Publication of the preliminary search report|Effective date: 20180504 |
    2020-02-20| PLFP| Fee payment|Year of fee payment: 4 |
    2021-02-19| PLFP| Fee payment|Year of fee payment: 5 |
    2022-02-18| PLFP| Fee payment|Year of fee payment: 6 |
    优先权:
    申请号 | 申请日 | 专利标题
    FR1660566A|FR3058292B1|2016-10-31|2016-10-31|METHOD FOR PROVIDING SERVICE TO A USER|
    FR1660566|2016-10-31|EP17198045.1A| EP3316549A1|2016-10-31|2017-10-24|Method for verifying the identity of a user by means of a public database|
    US15/798,153| US10817967B2|2016-10-31|2017-10-30|Method for controlling the identity of a user by means of a blockchain|
    [返回顶部]