Method and device for generating authentication information

Abstract

The invention relates to a method for generating authentication information associated with an individual having a given attribute, wherein a private key is associated with said given attribute (d'). The method comprises: - displaying a virtual keyboard (410) on an individual's device (102) in order to acquire secret information, the virtual keyboard comprising a plurality b of symbols that can be acquired, a set of private keys being associated with the symbols of the virtual keyboard; - acquiring, from the virtual keyboard, N symbols (420), the N acquired symbols forming a piece of acquired secret information; - determining the N private keys associated with the N symbols of the acquired secret information from the set of private keys associated with the symbols of the virtual keyboard (430); and - generating authentication information (440) from the N private keys associated with the N symbols of the acquired secret information, from the private key associated with the given attribute and from an authentication request message transmitted by a third-party device.

Description

[0001] Title of the invention: Method and device for generating authentication information

[0002] The present invention relates to a method of generating authentication information, particularly by an individual device, in order to achieve secure and reliable authentication of an individual attribute. Specifically, the invention relates to a method for generating authentication information associated with an individual possessing a given attribute and the associated individual device.

[0003] The verification of an individual's attribute by a third-party device, such as a device of an authority, is critical, particularly because the attribute relates to personal or confidential data, or a personal or confidential document of the individual.

[0004] Figure 1 illustrates a functional diagram 10 of prior art authentication of an individual. Specifically, when a service provider 20 needs to authenticate an individual or an attribute of an individual, it issues an authentication request to an identity provider 30. The latter will issue a challenge, for example, a random number, to the device of the individual 40 that needs to authenticate itself or authenticate an attribute of the individual. The individual enters a password or secret code on the device 40, which will generate an authentication token that will be transmitted to the identity provider. The identity provider will then authenticate the individual using the authentication token. The authentication result is then transmitted from the identity provider to the service provider.

[0005] Recent developments aim to decentralize an individual's attributes from the identity provider to the individual's device. Currently, an individual's attributes are preferably stored in digital wallets, also known as identity containers, which are software applications. These applications are stored, for example, on an individual's device, such as a mobile phone. They contain, in particular, the individual's personal identification data and may also contain the individual's electronic or qualified electronic attributes. For these attributes to be usable, a third party must be able to verify that the individual's attribute is correct and that it actually belongs to the individual. Therefore, it must be able to authenticate both the individual's attribute and the individual themselves.

[0006] The use of these identity containers therefore allows for a decentralization of individual attributes, as these are no longer stored in centralized servers but are distributed in identity containers stored in identity containers at the individual level.

[0007] Such decentralization implies that there is no longer a central server for authenticating individual attributes.

[0008] Furthermore, when an individual's device is in a mode that allows data sharing with a verification device, particularly one located near the individual's device, these two devices do not necessarily have an internet connection. However, the absence of such a connection prevents the verification device from authenticating the attribute holder.

[0009] A related issue arises from the use of a knowledge factor, such as a secret code or password, to grant access to an individual's attribute. This knowledge factor is stored on the individual's device, and the verification of the entered knowledge factor against the stored one is performed either by the device's system or by software. However, these control mechanisms lack security with regard to the personal and confidential attributes stored on the individual's device.

[0010] The purpose of the invention is to enable the generation of authentication information that can be verified by a third-party device that has or does not have an Internet connection, while ensuring a high level of assurance to resist attacks for access to these attributes.

[0011] This goal is achieved by a process of generating authentication information associated with an individual having a given attribute, a private key being associated with said given attribute.The process includes the following steps: displaying a virtual keyboard on an individual's device for the acquisition of secret information, the virtual keyboard comprising a plurality b of symbols that can be acquired, a set of private keys being associated with the symbols of the virtual keyboard; acquiring N symbols from the virtual keyboard, the N acquired symbols forming an acquired secret information; determining the N private keys associated with the N symbols of the acquired secret information in the set of private keys associated with the symbols of the virtual keyboard; generating authentication information from the N private keys associated with the N symbols of the acquired secret information, the private key associated with the given attribute, and an authentication request message transmitted by a third-party device.

[0012] This process allows the generation of authentication information which will then be used to perform strong authentication of the individual and the individual's attribute, through the use of several factors, namely by possession, in particular possession of the device, but also by inherence, namely for example by knowledge of secret information, for example, a secret code or a password, without however memorizing the secret information.

[0013] Authentication information can also be generated from validation information.

[0014] The generation of authentication information may include a step of generating an authentication key from the N private keys associated with the N symbols of the acquired secret information and the private key associated with the given attribute; and the authentication information may be generated from the generated authentication key and the authentication request message.

[0015] The generation of authentication information may include: a step of generating an authentication key from the N private keys associated with the symbols of the acquired secret information and the private key associated with the given attribute; and a step of generating an authentication secret key from the authentication key and the authentication request message, and the authentication information is generated by means of a cryptographic function from the generated authentication secret key.

[0016] The authentication secret key can be generated using at least one shared secret key calculation function from the authentication key and the authentication request message.

[0017] Said at least one shared secret key calculation function may include a key exchange function and optionally a key derivation function.

[0018] The authentication secret key can be generated by applying a Diffie-Hellman function from the authentication key and the authentication request message and by applying a key derivation function to the result of the Diffie-Hellman function.

[0019] The cryptographic function may include applying a message authentication code based on encryption. The authentication key can be generated using a mathematical function.

[0020] The mathematical function can be a multiplication.

[0021] The process may further include a step of validating the generated authentication key, the validation of the authentication key being able to be carried out by means of a public key associated with the given attribute of the individual, the step of generating the authentication information generated from the authentication key and the authentication request message being able to be carried out if the authentication key is validated.

[0022] The process may include a step of obtaining the authentication request message if the authentication key is validated.

[0023] The authentication key can also be generated from validation information.

[0024] The generation of authentication information may include a step of generating an authentication key from the N private keys associated with the N symbols of the acquired secret information, the authentication request message and the private key associated with the given attribute; the authentication information may be generated from the generated authentication key.

[0025] Authentication information can also be generated from validation information.

[0026] In the set of private keys associated with the symbols of the virtual keyboard, a private key can be associated with each symbol of the keyboard and with each possible position of the symbol in the entry of secret information.

[0027] The authentication request message can be a public parameter, a random or pseudo-random number, a coordinate of an elliptic curve point, or a public challenge key.

[0028] The validation information can be a private validation key.

[0029] A number of usage occurrences can be associated with the validation private key, and the validation private key can be regenerated when the number of usage occurrences of the validation private key has reached a given threshold.

[0030] The process may include a step of obtaining the authentication request message from the third-party device.

[0031] The invention also relates to a device configured to implement, at least in part, the method described above. The invention further relates to a system comprising a personal device and a hardware security module connected to the personal device, the system being configured to implement, at least in part, the method described above.

[0032] The invention also relates to a computer program comprising instructions that lead an individual device to perform at least some of the steps of the process described above.

[0033] The invention further relates to a computer-readable medium on which the previously described computer program is stored.

[0034] The invention further relates to a system comprising an individual device and a third-party device capable of verifying the authentication information generated by the individual device described above.

[0035] We will now describe examples of embodiments of the present invention with reference to the attached figures, where the same references designate identical or functionally similar elements from one figure to another:

[0036] FIG. 1 illustrates a functional authentication scheme according to the prior art.

[0037] FIG. 2 is a functional diagram of an example system according to the invention.

[0038] FIG. 3 illustrates a functional scheme for authenticating an individual having an ATT attribute in the system illustrated in figure 2.

[0039] FIG. 4 illustrates an embodiment of the method for generating authentication information implemented in the individual device of the system according to the invention.

[0040] FIG. 5 illustrates a set of private keys associated with the symbols of a virtual keyboard.

[0041] FIG. 6 illustrates a particular embodiment of step 440 of figure 4 according to the invention.

[0042] FIG. 7 illustrates another embodiment of the method for generating authentication information implemented in the individual device and a hardware security module of the system according to the invention.

[0043] FIG. 8 illustrates a particular embodiment of step 740 of figure 7 according to the invention.

[0044] FIG. 9 illustrates a particular embodiment of step 440 of figure 4 according to the invention.

[0045] Figure 10 illustrates another particular embodiment of step 440 of Figure 4 according to the invention. Figure 11 illustrates another particular embodiment of step 740 of Figure 7 according to the invention.

[0046] FIG. 12 illustrates another particular embodiment of step 740 of figure 7 according to the invention.

[0047] FIG. 13 illustrates another particular embodiment of step 440 of figure 4 according to the invention.

[0048] FIG. 14 illustrates another particular embodiment of step 740 of figure 7 according to the invention.

[0049] FIG. 15 illustrates the exchanges between an individual's device and a third-party device and the authentication by the third-party device of the authentication information of an individual's attribute according to the invention.

[0050] According to the present invention, an individual possesses an individual device and an attribute, and a verification device, namely a third-party device, must verify that the individual possesses the given attribute. To this end, authentication information is generated and transmitted, notably via a communication channel, for example a short-range one, from the individual device to the third-party device, and then authenticated.

[0051] The present invention relates to a method of generating authentication information associated with an individual having a given attribute in order to allow a third-party device to validate the individual's possession of the given attribute.

[0052] Figure 2 is a functional diagram of an example of a system 100 in which the method for generating authentication information according to the invention is implemented. According to one embodiment, the system 100 can be a system comprising two different computing devices, namely an individual device 102 and a third-party device 104, also called a verification device. These computing devices can communicate with each other via a communication channel 122. The communication channel is, for example, a wireless communication channel conforming to a short-range communication protocol (e.g., a connection conforming to the NFC standard, a connection conforming to the Wi-Fi standard, a connection conforming to the Bluetooth standard, etc.). The wireless communication channel can also be a communication channel conforming to a mobile communication protocol such as 4G or 5G.The communication channel will enable the transmission of authentication information generated from the individual's device to the third party's device. In another embodiment, the wireless communication channel can be implemented using an internet network via, for example, a protocol conforming to any of the Wi-Fi standards. The communication channel can also be a wired communication channel.

[0053] The individual device 102 can be a mobile device, such as a laptop, mobile phone, tablet, or wearable device. Wearable devices can include smartwatches or any other type of portable computing device. In some implementations, the individual device 102 can be a desktop computer or another type of non-wearable device, such as a kiosk.

[0054] The individual device 102 includes a hardware and software platform on which software runs, this software being either directly executable or interpreted on a virtual machine.

[0055] The individual device 102 includes a display device 106, a processing unit 108, such as a processor, capable of executing instructions, and a storage space 110.

[0056] The display device 106 includes, in particular, a human-machine interface for displaying data and receiving data from the user. This human-machine interface includes, for example, a screen and a keyboard, or a touchscreen.

[0057] The processing unit 108 is capable of running an operating system, which could be, for example, any type of commercially available operating system. The processing unit 108 may include means for executing at least one cryptographic algorithm.

[0058] Storage space 110 is capable of storing at least one attribute of the individual, such as one or more confidential data items or one or more personal data items. This at least one attribute of the individual may also be one or more personal and / or confidential documents or information, such as a digital identity document, a driver's license, diplomas, banking information such as an international bank account identifier, etc.

[0059] Storage space 110 can also store at least one private key associated with at least one attribute of the individual. In one embodiment, a private key is associated with one or more attributes of the individual. Alternatively, a different private key is associated with each attribute of the individual.

[0060] Storage space 110 may include, in particular, secure memory to store an individual's identity container containing one or more of the individual's attributes. The storage memory, including secure memory, may also be used to store cryptographic keys, such as at least one private key associated with at least one of the individual's attributes.

[0061] In another embodiment, the attribute(s) and / or the private key(s) associated with said attribute(s) of the individual may be stored in a device separate from the individual device, namely a hardware security module (HSM) such as a smart card. The hardware security module may further include a processing unit and / or means for executing at least one cryptographic algorithm. According to this embodiment, the individual device 102 and the hardware security module (HSM) each include communication means to enable them to exchange data via a communication channel 133, which may be a secure communication channel.

[0062] The storage space 110 of the individual device 102 can also store applications that can be executed by the processing unit 108 of the individual device 102. In particular, the storage space can store a computer program. The computer program is configured to implement all or part of a method for generating authentication information according to the invention, which will be described above. The computer program includes instructions that can be executed, at least in part, by the processing unit 108, which cause the individual device to execute, at least in part, the steps of the method for generating authentication information.According to another embodiment, the computer program includes instructions that can be executed partly by the processing unit 108 of the individual device 102 and partly by a hardware security module HSM, which lead to the execution of all or part of the steps of the process to generate authentication information.

[0063] The computer program can be stored on a computer-readable medium. This computer-readable medium may include memory for storing instructions. The memory can include any type of memory suitable for storing data and executable instructions, such as read-only memory (ROM), rewritable flash memory, and a hard drive.

[0064] The individual device 102 may further include communication means 112 capable of communicating with another device, for example, a third-party device 104. The communication means 112 include, in particular, a function for establishing a secure communication channel, enabling the creation of a secure channel 122 between the individual device 102 and a remote device 104. The communication means 112 allow for network-type connectivity, either via a wired connection or via a wireless connection (for example, conforming to the Bluetooth standard, the NFC standard, the Wi-Fi standard (for example, Wi-Fi Direct), or the PC / SC standard). The communication means 112 may include, in particular, a module enabling proximity-based communication.

[0065] The 104 third-party device can be a mobile device from a third-party vendor, such as a laptop, smartphone, tablet, or wearable device. Wearable devices can include smartwatches or any other type of portable computing device. In some implementations, the 104 third-party device can be a desktop computer, server, or other type of non-wearable device, such as a kiosk.

[0066] The tier 104 device includes a hardware and software platform on which software runs, this software being either directly executable or interpreted on a virtual machine.

[0067] The third-party device 104 includes a display device 114, a processing unit 116, such as a processor, capable of executing instructions, and a storage memory 118.

[0068] The display device 114 includes, in particular, a human-machine interface for displaying data and receiving data from the device user or from third parties. This human-machine interface includes, for example, a screen and keyboard, or a touchscreen.

[0069] The processing unit 116 is capable of running an operating system, which could be, for example, any type of commercially available operating system. The processing unit 116 may include means for executing at least one cryptographic algorithm.

[0070] The storage memory 118 can also store applications suitable for execution by the processing unit 116 of the third-party device 104. The storage memory 118 can include, in particular, a secure memory for storing cryptographic keys s.

[0071] The third-party device 104 may further include communication means 120 capable of communicating with another device, for example, a personal device 102. The communication means 120 include, in particular, a function for establishing a secure communication channel, enabling the creation of a secure channel 122 between the third-party device 104 and a personal device 102. The communication means 120 allow for network-type connectivity, either via a wired connection or via a wireless connection (for example, conforming to the Bluetooth standard, NFC, RFID, Wi-Fi standard (for example, Wi-Fi Direct), or PC / SC). The communication means 120 include, in particular, a module enabling proximity-based communication.

[0072] According to a particular implementation example, communication channel 122 complies with the NFC standard.

[0073] Figure 3 illustrates a functional diagram of authentication of an individual having an ATT attribute in the system illustrated in Figure 2. This figure illustrates, in contrast to the functional diagram in Figure 1, a mechanism for authenticating an individual having an attribute without the use of an identity provider.

[0074] According to the system illustrated in Figure 3, an individual has an individual device 102 and an attribute ATT for example stored in the individual device 102. The individual device implements a method for generating TOKEN authentication information associated with the individual having a given attribute in accordance with the invention.

[0075] As illustrated, the third-party device 104 sends an authentication request 310 to an individual device 102, which includes an attribute of the individual to be verified and obtained.

[0076] This attribute is, for example, the driver's license as illustrated in Figure 3. In other words, the third-party device 104, via this request, wishes to obtain the individual's driver's license as well as authentication information, allowing it to authenticate the individual's driver's license that it will receive from the latter.

[0077] Upon receiving this request, the individual device 102 will generate a TOKEN authentication information associated with the individual having the given attribute ATT and then transmit a response 320 containing the generated authentication information as well as the attribute of the requested individual to the third-party device 104.

[0078] Thus, in the illustrated example, the individual's device will send the individual's driver's license and the generated authentication information to the third-party device.

[0079] Upon receiving the authentication information, the third-party device 104 verifies said information in order to authenticate the individual having the requested attribute and accesses the attribute of the requested individual, namely in the illustrated example, the individual's driver's license.

[0080] The method for generating a TOKEN authentication information associated with an individual possessing a given ATT attribute is illustrated in this figure and the following figures. However, if the individual possesses multiple attributes requested by the third-party device, then several authentication information pieces can be generated according to the invention. In other words, one authentication information piece can be generated for each requested individual attribute. Alternatively, a single authentication information piece could be generated for all the requested attributes.

[0081] Figure 4 illustrates an implementation of the method for generating TOKEN authentication information associated with an individual possessing a given attribute ATT, according to a first embodiment of the invention. In this method, a private key is associated with the individual's given attribute. In the particular embodiment where the individual possesses multiple attributes, such as their digital identity card and driver's license, each attribute is associated with a private key. Alternatively, the same private key can be associated with multiple attributes.

[0082] The process can begin with a step in which the individual's device obtains a cG 405 authentication request message. The cG authentication request message can be a public parameter, a random or pseudo-random number, an elliptic curve point G, or a public challenge key. The public challenge key can, for example, be generated from a secret challenge key c (for example, known only to the third-party device) and an elliptic curve point G.

[0083] The elliptical curve point G is a known datum of the individual device and the third party device.

[0084] According to the particular embodiment considered in the following, the cG authentication request message is a challenge public key.

[0085] The process then continues by displaying a virtual keyboard on the individual's device for acquiring secret information (step 410). The virtual keyboard can be displayed using a graphical interface comprising a virtual keyboard suitable for display on the display device 106 of the individual's device 102. This graphical interface includes all the symbols that can be combined to form secret information. The virtual keyboard therefore comprises a plurality b of symbols that can be acquired. The symbols can be numeric or alphanumeric characters with or without punctuation marks. The symbols can also be images, icons, signs to create a pattern, a video sequence comprising selectable visual objects, or words that can form a sentence.Private keys associated with the symbols on the virtual keyboard form a set of private keys associated with the symbols on the virtual keyboard. This set is stored in the individual's device 102.

[0086] According to a particular embodiment, in the set of private keys associated with the symbols of the virtual keyboard, a private key is associated with each symbol of the keyboard.

[0087] In another embodiment, in the set of private keys associated with the symbols of the virtual keyboard, a private key is associated with each symbol on the keyboard and with each input position of the symbol. In other words, a private key is associated with each symbol b according to an input position i in the secret information. Thus, according to this embodiment, the set of private keys associated with the symbols of the virtual keyboard comprises, for example, 40 private keys in the case where the virtual keyboard has 10 symbols and the secret information consists of 4 symbols. Figure 5 illustrates a set of private keys associated with the symbols of the virtual keyboard (P0,1; P1,1; ...; P9,4), in the context of a virtual keyboard with numeric symbols from 0 to 9 and secret information consisting of 4 symbols. Thus, for example, the symbol 4 entered in the second position will have as its private key P4,2, as illustrated.According to another embodiment, the private key associated with a symbol and its position in the entry of the secret information can be determined by applying a private key determination function.

[0088] After the display of the virtual keyboard on the individual device 102, the process continues with a step of acquiring N symbols pi on the virtual keyboard, the N acquired symbols pi together forming a secret information p (step 420).

[0089] The process continues with a step of determining the N private keys associated with the N symbols of the secret information acquired p in the set of private keys associated with the symbols of the virtual keyboard (step 430).

[0090] The N private keys associated with the N symbols of the acquired secret information p are determined from the set of private keys associated with the symbols on the keyboard, for example as a function of the symbol entered p and according to a particular embodiment, of the position i of the symbol entry.

[0091] The process continues with the generation of a TOKEN authentication information (step 440) from the N private keys associated with the N symbols of the acquired secret information p, the private key associated with the given attribute of , and an authentication request message cG transmitted by a third-party device. In one particular embodiment, the generation of the TOKEN authentication information may also include one or more other parameters or data.

[0092] Step 440 of generating TOKEN authentication information can be carried out in individual device 102.

[0093] Alternatively, when the individual's ATT attribute and the private key associated with the given attribute are stored in a hardware security module (HSM), step 440 of generating TOKEN authentication information can be performed at least in part in the hardware security module (HSM) as detailed below in the support for Figure 6. In this case, the TOKEN authentication information generated by the hardware security module (HSM) is then transmitted to the individual's device 102.

[0094] After the token authentication information is generated, the individual device 102 can then transmit this authentication information to the third-party device 104, as illustrated in Figure 3. This authentication information is transmitted, for example, to the third-party device along with the requested attribute. Other data can also be transmitted to the third-party device 104 with the authentication information, such as the individual's identity signed by the entity that issued the individual's attribute, and one or more attribute data points that will be disclosed to the third-party device. The signed identity can include a masked individual identity data point, a public key associated with the given individual attribute D, and / or the signature of the signed identity.

[0095] According to this process, the individual's secret information is not stored in the individual's device, thus improving the security of the individual's secret information concerning the ATT attribute.

[0096] Figure 6 illustrates a particular embodiment of step 440 of Figure 4, namely, the generation of the authentication information associated with the individual and the individual's ATT attribute from the N private keys associated with the N symbols of the acquired secret information p, the private key associated with the given attribute d', and an authentication request message cG, specifically when the private key associated with the given attribute d' is stored in a hardware security module (HSM). According to this embodiment, the individual's ATT attribute can also be stored in the hardware security module.

[0097] According to this embodiment, the authentication information is generated in the HSM security hardware module.

[0098] In this case, the N private keys associated with the symbols of the acquired secret information and the cG authentication request message can be communicated by the individual device 102 to the HSM security hardware module (step 610) via the communication channel 133 so that the HSM security hardware module is able to generate the TOKEN authentication information from the N private keys associated with the symbols of the acquired secret information, the private key associated with the given attribute of and the cG authentication request message.

[0099] The N private keys associated with the symbols of the secret information can be transmitted as such from the individual's device to the hardware security module. Alternatively, they can be transmitted as assembled data generated by a key association operation using the N private keys associated with the acquired symbols of the secret information. The assembled data can also contain the cG authentication request message.

[0100] One embodiment of the association operation will be described below. In the embodiment in which assembled data is generated, the latter is transmitted from the individual device 102 to the HSM security hardware module.

[0101] Authentication information is then generated (step 620) in the HSM security hardware module, either from the N private keys associated with the symbols of the secret information of the private key associated with the given attribute and the cG authentication request message, or from the assembled data, the private key associated with the given attribute and the cG authentication request message (if it has not been assembled in the assembled data). The authentication information generated by the HSM security hardware module is then transmitted to the individual device 102.

[0102] If the individual's ATT attribute is stored in the security hardware module, it can also be transmitted to the individual device 102.

[0103] The association operation will now be described.

[0104] According to one embodiment, each symbol on the virtual keyboard is associated with a private key P pAccording to this embodiment, the assembled data pc is determined, for example, in the following way: pc = In the case where the assembled data also includes the cG authentication request message, then the assembled data pc is determined, for example, as follows: pc = Other mathematical functions besides multiplication can be used to perform key association.

[0105] According to another embodiment, each symbol p on the virtual keyboard and each position i of the symbol in the input of the secret information is associated with a private key P p i. According to this embodiment, the assembled data pc is determined, for example, as follows: pc = In the case where the assembled data also includes the cG authentication request message, then the assembled data pc is determined, for example, as follows: pc = \i =1 Pp i . cG . Other mathematical functions besides multiplication can be used to perform key association.

[0106] Figure 7 illustrates an implementation of the method for generating TOKEN authentication information associated with an individual having a given attribute ATT according to a second embodiment of the invention. According to this embodiment, steps 405, 410, 420, and 430 of Figure 7 are identical to steps 405, 410, 420, and 430 illustrated in Figure 4 and described above. In particular, the embodiment illustrated in Figure 7 differs from that described in Figure 4 with respect to the step of generating TOKEN authentication information. Indeed, according to this embodiment, TOKEN authentication information is generated from the N private keys associated with the N symbols of the acquired secret information p, the private key associated with the given attribute d', an authentication request message cG, and a validation information v.

[0107] According to this embodiment, the individual device includes validation information v. The validation information v can be a validation private key v. In this case, a number of usage occurrences can be associated with the validation private key v such that after a given number of uses of the validation private key v, this key must be regenerated. In other words, the validation private key (v) is regenerated when the number of usage occurrences of the validation private key has reached a given threshold. According to another particular embodiment, the validation information v is a number of usage occurrences capable of being incremented with each execution of the generation process. The number of usage occurrences is incremented after each entry of secret information.

[0108] According to the embodiment illustrated in Figure 7, the process includes a step 740 of generating a TOKEN authentication information from N private keys associated with the N symbols of the acquired secret information p, the private key associated with the given attribute d', an authentication request message cG, and the validation information v. According to a particular embodiment, the generation of the TOKEN authentication information may also include one or more other parameters or data.

[0109] As previously described, the N private keys associated with the N symbols of the acquired secret information are determined from the set of private keys associated with the symbols on the keyboard as a function of the symbol entered p and, according to a particular embodiment, of the position i of the symbol entry.

[0110] The step of generating TOKEN authentication information can be carried out in the individual device 102.

[0111] Alternatively, when the private key associated with the given attribute is stored in a hardware security module (HSM), the step of generating TOKEN authentication information can be performed, at least partially, within the HSM, as detailed below in Figure 8. In this case, the individual's ATT attribute can also be stored in the HSM. The TOKEN authentication information generated by the HSM is then transmitted to the individual's device 102. If the HSM stores the individual's ATT attribute, this attribute can also be transmitted to the individual's device 102.

[0112] Figure 8 illustrates a particular embodiment of step 740 of Figure 7, namely, the generation of the authentication information associated with the individual and the individual's ATT attribute from the N private keys associated with the N symbols of the acquired secret information p, the private key associated with the given attribute d', an authentication request message cG, and the validation information v, particularly when the private key associated with the given attribute d' is stored in a hardware security module (HSM). According to this embodiment, the individual's ATT attribute can also be stored in the hardware security module.

[0113] According to this embodiment, the authentication information is generated in the HSM security hardware module.

[0114] In this case, the N private keys associated with the symbols of the acquired secret information, the cG authentication request message and the validation information v can be communicated by the individual device 102 to the HSM security hardware module (step 810) via the communication channel 133 so that the HSM security hardware module is able to generate the TOKEN authentication information from the N private keys associated with the symbols of the acquired secret information, the private key associated with the given attribute of, a cG authentication request message transmitted by the third-party device and the validation information v.

[0115] The N private keys associated with the symbols of the secret information can be transmitted as such from the individual's device to the hardware security module. Alternatively, they can be transmitted as assembled data generated by a key association operation from the N private keys associated with the symbols of the acquired secret information. The assembled data can also contain the cG authentication request message and / or the v validation information.

[0116] One embodiment of the association operation will be described below. In the embodiment in which assembled data is generated, the latter is transmitted from the individual device 102 to the HSM security hardware module.

[0117] Authentication information is then generated (step 820) in the HSM security hardware module, either from the N private keys associated with the symbols of the secret information of the private key associated with the given attribute, the cG authentication request message, and the validation information v, or from the assembled data, the private key associated with the given attribute, the cG authentication request message, and the validation information v (if the cG authentication request message and / or the validation information v have not been assembled into the assembled data). The authentication information generated by the HSM security hardware module is then transmitted to the individual device 102.

[0118] If the individual's ATT attribute is stored in the security hardware module, it can also be transmitted to the individual device 102.

[0119] According to one embodiment, each symbol on the virtual keyboard is associated with a private key P p According to this embodiment, the assembled data pc is determined, for example, as follows: pc In the case where the assembled data also includes the cG authentication request message, then the assembled data pc is determined, for example, as follows: pc = In the case where the assembled data also includes the authentication request message cG and the validation information v, then the assembled data pc is determined, for example, as follows: pc = \i =1 P p . cG. v. Other mathematical functions besides multiplication can be used to implement key association. According to another embodiment, each symbol p on the virtual keyboard and each position i of the symbol in the input of the secret information is associated with a private key P pi. According to this embodiment, the assembled data pc is determined, for example, as follows: pc = n^=i Pp,i- In the case where the assembled data also includes the authentication request message cG, then the assembled data pc is determined, for example, as follows: pc = \i =1 P p i . cG . In the case where the assembled data also includes the authentication request message cG and the validation information v, then the assembled data pc is determined, for example, as follows: pc = \i =1 P p i . cG. v. Other mathematical functions besides multiplication can be used to perform key association.

[0120] Figures 9 and 10 illustrate embodiments of the authentication information generation step described in step 440 of Figure 4 and Figures 11 and 12 illustrate embodiments of the authentication information generation step described in step 740 of Figure 7.

[0121] Figure 9 relates to a particular embodiment of step 440 of Figure 4, namely, the generation of the authentication information associated with the individual and the ATT attribute of the individual from the N private keys associated with the N symbols of the acquired secret information p, the private key associated with the given attribute of and an authentication request message cG.

[0122] According to the embodiment illustrated in Figure 9, the generation of the authentication information includes a step of generating an authentication key d (step 910). According to this embodiment, the authentication key d is generated from N private keys associated with the symbols of the acquired secret information and the private key associated with the given attribute of d'.

[0123] According to a particular embodiment, the step of generating an authentication key d can be preceded by a key association operation, specifically of the N private keys associated with the symbols of the secret information acquired to form an assembled data pc. The association operation can, for example, be one of the association operations described above in Figure 6.

[0124] According to another particular embodiment, the key association operation is performed as follows: a Diffie-Hellman function is applied to the secret key associated with the first symbol of the secret information (whether or not this secret key is position-dependent on the symbol within the secret information) and to the authentication request message cG. The Diffie-Hellman function may include the Diffie-Hellman function on large integers and any other Diffie-Hellman function such as ECDH. The x-coordinate of the result of the function is, for example, retained for the next step in the key association operation, namely plcG. Next, a Diffie-Hellman function is applied to the secret key associated with the second symbol of the secret information and to the key association already performed, namely plcG. The process is continued for each symbol of the secret information to obtain an assembled data pc.This embodiment of the generation of the assembled pc data can also be used in the embodiment described in the support of Figure 6.

[0125] The authentication key d is then generated using a mathematical function fctl from the generated assembled data pc and the private key associated with the given attribute d': d = fctl(pc, d').

[0126] Step 910 can be followed by an optional validation step of the generated authentication key d (step 920). The validation of the authentication key d is performed using a public key associated with the given attribute of individual D. In this case, the public key associated with the given attribute of individual D can be stored in the individual's device. According to this embodiment, the public key associated with the given attribute of individual D has been previously generated from the public keys associated with the private keys associated with the symbols of the individual's secret information and the private key associated with the given attribute of d and the elliptic curve point G.

[0127] According to a particular embodiment, if the authentication key d is validated in step 920, then the process can continue with a step of obtaining the cG authentication request message (step 930). In this case, this step replaces the optional step 405 described in Figure 4. This embodiment has the advantage of obtaining the cG authentication request message only if the generated authentication key d has been verified and is correct.

[0128] Step 920 is also omitted and step 405 is maintained if the previously presented key association operation is performed using the cG authentication request message.

[0129] According to an alternative embodiment, step 930 is not carried out at the end of step 920 but is carried out at step 405 according to figure 4.

[0130] The next step, illustrated in Figure 9, is the generation of the TOKEN authentication information (step 940). The TOKEN authentication information is generated from the generated authentication key d and the authentication request message cG.

[0131] The authentication information TOKEN can be generated using a mathematical function fct2 from the generated authentication key d and the authentication request message cG: TOKEN = fct2(d, cG).

[0132] Figure 10 relates to another particular embodiment of step 440 of Figure 4, namely, the generation of the authentication information associated with the individual and the individual's ATT attribute from the N private keys associated with the N symbols of the acquired secret information p, the private key associated with the given attribute of and an authentication request message cG.

[0133] Steps 910, 920 and 930 in Figure 10 refer to steps identical to steps 910, 920 and 930 illustrated in Figure 9 and described above.

[0134] According to this embodiment, step 940 of Figure 9 is replaced by steps 1035 and 1040 of Figure 10. In particular, in step 1035, the process includes a step of generating an authentication secret key Ks from the authentication key d and the authentication request message cG.

[0135] According to one embodiment, the authentication secret key Ks is generated by means of at least one shared secret key calculation function from the authentication key d and the obtained authentication request message cG.

[0136] According to this embodiment, the authentication secret key Ks is shared with the third-party device. Indeed, if the secret information has been correctly entered by the individual on their device, then the generated authentication secret key Ks is the key shared with the third-party device; that is, it is stored in the third-party device so that the latter can verify the authentication information generated on the individual's device.

[0137] Said at least one shared secret key calculation function may include a key exchange function (Diffie-Hellman) and / or a key derivation function (KDF). The Diffie-Hellman function may include the Diffie-Hellman function on large integers and any other Diffie-Hellman function such as ECDH.

[0138] In one particular embodiment, the authentication secret key Ks is generated by applying a Diffie-Hellman function to the authentication key d and the authentication request message cG, and then applying a key derivation function to the result of the Diffie-Hellman function. For example, the authentication secret key Ks is generated as follows: Ks = KDF(DH(d, cG)) where KDF is a key derivation function and DH is a Diffie-Hellman function.

[0139] According to the process illustrated in Figure 10, step 1035 is followed by step 1040, during which the TOKEN authentication information is generated using a cryptographic function from the generated authentication secret key Ks. The TOKEN authentication information can also be generated from an identity signed by the entity that issued the individual's attribute and from one or more attribute data points that will be disclosed to the third-party device. The signed identity can include a masked individual identity data point, a public key associated with the given individual attribute D (generated, for example, from the authentication key d and the elliptic curve point G), and / or the signature of the signed identity.

[0140] The cryptographic function may include the application of a message authentication code based on encryption, such as CMAC. The cryptographic function could also be a hash function.

[0141] Figure 11 relates to a particular embodiment of step 740 of Figure 7, namely, the generation of the authentication information associated with the individual and the ATT attribute of the individual from the N private keys associated with the N symbols of the acquired secret information p, the private key associated with the given attribute d', an authentication request message cG and the validation information v.

[0142] According to the embodiment illustrated in Figure 11, the generation of the authentication information includes a step of generating an authentication key d (step 1110). According to this embodiment, the authentication key d is generated from N private keys associated with the symbols of the acquired secret information, the private key associated with the given attribute of and a validation information v.

[0143] In one particular embodiment, the step of generating an authentication key is preceded by a key association operation, specifically the N private keys associated with the symbols of the acquired secret information to form a data assembly pc. The association operation can, for example, be one of the association operations described above in Figure 8.

[0144] According to another particular embodiment, the key association operation is carried out in the manner previously described in the support of Figure 9 using a Diffie-Hellman function. This embodiment of the generation of the assembled data pc can also be used in the embodiment described in the support of Figure 8. The authentication key d is then generated by means of a mathematical function fct3 from the generated assembled data pc, the private key associated with the given attribute d' and the validation information v: d = fct3(pc, v, d').

[0145] Step 1110 can be followed by an optional validation step of the generated authentication key d (step 1120). The validation of the authentication key d is performed using a public key associated with the given attribute of individual D. In this case, the public key associated with the given attribute of individual D can be stored in the individual's device. According to this embodiment, the public key associated with the given attribute of individual D has previously been generated from the public keys associated with the private keys associated with the symbols of the individual's secret information, the private key associated with the given attribute d, the validation information v, and the elliptic curve point G.

[0146] According to a particular embodiment, if the authentication key d is validated in step 1120, then the process can continue with a step of obtaining the cG authentication request message (step 1130). In this case, this step replaces the optional step 705 described in Figure 7. This embodiment has the advantage of obtaining the cG authentication request message only if the generated authentication key d has been verified and is correct.

[0147] Step 1120 is also omitted and step 705 is maintained if the previously presented key association operation is performed using the cG authentication request message.

[0148] According to an alternative embodiment, step 1130 is not carried out at the end of step 1120 but is carried out at step 705 according to figure 7.

[0149] The next step, illustrated in Figure 11, is the generation of the TOKEN authentication information (step 1140). The TOKEN authentication information is generated from the generated authentication key d and the authentication request message cG.

[0150] The authentication information JETON can be generated using a mathematical function fct4 from the generated authentication key d and the authentication request message cG: JETON = fct4(d, cG).

[0151] Figure 12 relates to another particular embodiment of step 740 of Figure 7, namely, the generation of the authentication information associated with the individual and the individual's ATT attribute from the N private keys associated with the N symbols of the acquired secret information p, the private key associated with the given attribute d', an authentication request message cG of the validation information v.

[0152] Steps 1110, 1120 and 1130 in Figure 12 refer to steps identical to steps 1110, 1120 and 1130 illustrated in Figure 11 and described above.

[0153] According to this embodiment, step 1140 of Figure 11 is replaced by steps 1235 and 1240 of Figure 12.

[0154] Steps 1235 and 1240 of Figure 12 can be carried out in a similar manner to steps 1035 and 1040 of Figure 10.

[0155] In particular, at step 1235, the process includes a step of generating an authentication secret key Ks from the authentication key d and the authentication request message cG.

[0156] According to one embodiment, the authentication secret key Ks is generated by means of at least one shared secret key calculation function from the authentication key d and the authentication request message cG.

[0157] According to this embodiment, the authentication secret key Ks is shared with the third-party device. Indeed, if the secret information has been correctly entered by the individual on their device, then the generated authentication secret key Ks is the key shared with the third-party device; that is, it is stored in the third-party device so that the latter can verify the authentication information generated on the individual's device.

[0158] Said at least one shared secret key calculation function may include a key exchange function (Diffie-Hellman) and / or a key derivation function (KDF). The Diffie-Hellman function may include the Diffie-Hellman function on large integers and any other Diffie-Hellman function such as ECDH.

[0159] In one particular embodiment, the authentication secret key Ks is generated by applying a Diffie-Hellman function to the authentication key d and the authentication request message cG, and then applying a key derivation function to the result of the Diffie-Hellman function. For example, the authentication secret key Ks is generated as follows: Ks = KDF(DH(d, cG)) where KDF is a key derivation function and DH is a Diffie-Hellman function.

[0160] According to the process illustrated in Figure 12, step 1235 is followed by step 1240, during which the TOKEN authentication information is generated using a cryptographic function from the generated authentication secret key Ks. The TOKEN authentication information can also be generated from an identity signed by the entity that issued the individual's attribute and from one or more attribute data points that will be disclosed to the third-party device. The signed identity can include a masked individual identity data point, a public key associated with the given individual attribute D (generated, for example, from the authentication key d and the elliptic curve point G), and / or the signature of the signed identity.

[0161] The cryptographic function includes applying a message authentication code based on encryption, such as CMAC. The cryptographic function could also be a hash function.

[0162] Figure 13 illustrates another particular embodiment of step 440 of Figure 4, namely, the generation of the authentication information associated with the individual and the individual's ATT attribute from the N private keys associated with the N symbols of the acquired secret information p, the private key associated with the given attribute of and an authentication request message cG.

[0163] The generation of the TOKEN authentication information includes a step of generating an authentication key d (step 1310) from the N private keys associated with the symbols of the acquired secret information, the obtained cG authentication request message and the private key associated with the given attribute of d'.

[0164] In one particular embodiment, the step of generating an authentication key d is preceded by a key association operation, specifically of the N private keys associated with the symbols of the secret information acquired to form an assembled data pc. The association operation can be, for example, one of the association operations described above in Figure 6 or Figure 9.

[0165] The authentication key d is then generated using a mathematical function fct5 from the assembled data pc, the authentication request message cG obtained and the private key associated with the given attribute d': d = fct5(pc, cG, d').

[0166] The next step illustrated in Figure 13 is the step of generating the TOKEN authentication information (step 1320). According to this embodiment, the TOKEN authentication information is generated from the generated authentication key.

[0167] Thus, the authentication information JETON is generated by means of a mathematical function fctô from the generated authentication key d: JETON = fct6(d).

[0168] As illustrated in Figure 3, following the generation of the TOKEN authentication information, this information is transmitted to the third-party device for authentication. This transmission may also include the identity signed by the entity that issued the individual's attribute and one or more data points from the attribute that will be disclosed to the third-party device. The signed identity may include a masked individual's identity data point, a public key for the attribute associated with individual D (generated, for example, from the authentication key d and the elliptic curve point G), and / or the signature of the signed identity.

[0169] Figure 14 illustrates another particular embodiment of step 740 of Figure 7, namely, the generation of the authentication information associated with the individual and the individual's ATT attribute from the N private keys associated with the N symbols of the acquired secret information p, the private key associated with the given attribute d', an authentication request message cG, and validation information v.

[0170] The generation of the TOKEN authentication information includes a step of generating an authentication key d (step 1410) from the N private keys associated with the symbols of the acquired secret information, the obtained cG authentication request message and the private key associated with the given attribute of d'.

[0171] In one particular embodiment, the step of generating an authentication key d is preceded by a key association operation, specifically of the N private keys associated with the symbols of the secret information acquired to form an assembled data pc. The association operation can be, for example, one of the association operations described above in Figure 8 or Figure 11.

[0172] The authentication key d is then generated using a mathematical function fct7 from the assembled data pc, the authentication request message cG obtained and the private key associated with the given attribute d': d = fct7(pc, cG, d').

[0173] The next step illustrated in Figure 14 is the step of generating the TOKEN authentication information (step 1420). According to this embodiment, the TOKEN authentication information is generated from the generated authentication key.

[0174] Thus, the authentication information JETON is generated by means of a mathematical function fct8 from the generated authentication key d and the validation information v: JETON = fct8(d, v).

[0175] As illustrated in Figure 3, following the generation of the TOKEN authentication information, the latter is transmitted to the third-party device in order to be authenticated.

[0176] This transmission may also include the identity signed by the entity that issued the individual's attribute and one or more data points from the attribute that will be disclosed to the third-party device. The signed identity may include a masked individual's identity data point, a public key for the attribute associated with the individual D (generated, for example, from the authentication key d and the elliptic curve point G), and / or the signature of the signed identity.

[0177] Figure 15 corresponds to the system of Figure 3. This figure illustrates the exchanges between the individual device 102 and the third-party device 104 and the authentication by the third-party device of the authentication information of an attribute of an individual in accordance with the invention.

[0178] As illustrated in Figure 15, the third-party device 104 sends a request 1510 to the individual device 102 with the requested attribute as a parameter. A cG authentication request message can also be sent from the third-party device to the individual device 102, for example, in the request 1510 or via another message. Indeed, as seen previously, in some embodiments the cG authentication request message can be transmitted to the individual device 102 at a later date.

[0179] The individual device 102 will implement the process of generating authentication information associated with an individual having the requested attribute as detailed previously and illustrated in figures 4 to 14.

[0180] Following the generation of the TOKEN authentication information, the individual device 102 transmits this information to the third-party device 104 for authentication. The requested attribute can also be transmitted from the individual device 102 to the third-party device.

[0181] This transmission may also include the identity signed by the entity that issued the individual's attribute and one or more data points from the attribute. The signed identity may include a masked individual's identity data point, a public key for the attribute associated with individual D, and / or the signature of the signed identity.

[0182] The third-party 104 device will then proceed to authenticate the requested attribute.

[0183] To perform this authentication, the third-party device 104 has the challenge secret key c. The challenge secret key ca allowed the third-party device 104 to generate the authentication request message cG, which was then transmitted to the individual's device 102 for the generation of the TOKEN authentication information. In a particular embodiment, the challenge secret key c is generated for each new session. Therefore, the authentication request message cG is different for each new session. Using the public key of the attribute associated with individual D and the challenge secret key c, the third-party device 104 will generate a verification authentication information JETON-VERIF.

[0184] The verification TOKEN authentication information may, for example, initially consist of generating an authentication secret key Ks from the public key of the individual D and the challenge secret key c.

[0185] The public key of the attribute associated with individual D can be generated, for example, from the public keys of the symbols composing the secret information of the individual and the public key of G of the attribute ATT to be authenticated and the validation public key vG.

[0186] According to one embodiment, the public key of the attribute associated with the individual D can be generated for example from the private keys of the symbols composing the secret information of the individual and the private key of the attribute ATT to be authenticated and the validation private key v, and the point of an elliptic curve G.

[0187] In one particular embodiment, the authentication secret key Ks is generated by the third-party device by applying a Diffie-Hellman function to the public key of the attribute associated with the individual D and the challenge secret key c, and by applying a key derivation function to the result of the Diffie-Hellman function. Thus, the authentication secret key Ks is generated, for example, as follows: Ks = KDF(DH(c, D)) where KDF is a key derivation function and DH is a Diffie-Hellman function.

[0188] In another embodiment, since the authentication secret key Ks is shared by the individual's device and the third-party device, the latter stores the authentication secret key Ks. The authentication secret key Ks generated by the third-party device is the symmetric key of the one generated by the individual's device.

[0189] The third-party device will then generate the verification TOKEN authentication information from the Ks authentication secret key, for example by means of a cryptographic function from the generated Ks authentication secret key.

[0190] The TOKEN-VERIF authentication information can also be generated from an identity signed by the entity that issued the individual's attribute and from one or more attribute data points that will be disclosed to the third-party device. The signed identity may include a masked individual identity data point, a public key for the attribute associated with individual D, and / or the signature of the signed identity. The cryptographic function may include the application of a message authentication code based on encryption, such as CMAC. The cryptographic function could also be a hash function.

[0191] The third-party device then verifies that the received TOKEN authentication information matches the TOKEN-VERIF verification authentication information. If so, the individual's attribute has been successfully authenticated. In other words, the individual has entered the correct secret information on the individual's device for the requested attribute.

Claims

Demands 1. Method of generating an authentication information (TOKEN) associated with an individual having a given attribute (ATT), a private key being associated with said given attribute (d'), the method comprising the following steps: displaying a virtual keyboard (410) on an individual's device (102) for the acquisition of a secret information, the virtual keyboard comprising a plurality b of symbols that can be acquired, a set of private keys being associated with the symbols of the virtual keyboard, acquisition from the virtual keyboard, of N symbols (pi) (420), the N acquired symbols (pi) forming an acquired secret information (p); determination of the N private keys associated with the N symbols of the acquired secret information (p) in the set of private keys associated with the symbols of the virtual keyboard (430);generation of an authentication information (TOKEN) (440) from the N private keys associated with the N symbols of the acquired secret information (p), the private key associated with the given attribute (d') and an authentication request message (cG) transmitted by a third-party device.; 2. Generation method according to the preceding claim, wherein the authentication information (TOKEN) is further generated from validation information (v) (740).

3. Generation method according to claim 1, wherein the generation of the authentication information (TOKEN) comprises a step of generating an authentication key (d) (910) from the N private keys associated with the N symbols of the acquired secret information and the private key associated with the given attribute (d'); and the authentication information (TOKEN) is generated from the generated authentication key (d) and the authentication request message (cG) (940).

4. A generation method according to claim 1, wherein the generation of the authentication information (TOKEN) comprises: a step of generating an authentication key (d) from the N private keys associated with the symbols of the acquired secret information and the private key associated with the given attribute (d') (910); and a step of generating an authentication secret key (Ks) (1035) from the authentication key (d) and the authentication request message (cG) and the authentication information (TOKEN) is generated by means of a cryptographic function from the generated authentication secret key (Ks) (1040).

5. Generation method according to the preceding claim, wherein the authentication secret key (Ks) is generated by means of at least one shared secret key calculation function from the authentication key (d) and the authentication request message (cG).

6. A generation method according to the preceding claim, wherein said at least one shared secret key calculation function comprises a key exchange function (Diffie-Hellman) and optionally a key derivation function (KDF).

7. Generation method according to claim 4, wherein the authentication secret key (Ks) is generated by applying a Diffie-Hellman function from the authentication key (d) and the authentication request message (cG) and by applying a key derivation function to the result of the Diffie-Hellman function.

8. Generation method according to any one of claims 4 to 7, wherein the cryptographic function includes the application of a message authentication code based on encryption (CMAC).

9. Generation method according to any one of claims 3 to 8, wherein the generation of the authentication key (d) is carried out by means of a mathematical function.

10. Generation method according to the preceding claim, characterized in that the mathematical function is a multiplication.

11. A generation method according to any one of claims 3 to 10, wherein the method further comprises a step of validating the generated authentication key (d), the validation of the authentication key (d) being carried out by means of a public key associated with the given attribute of the individual (D), the step of generating the authentication information (TOKEN) generated from the authentication key (d) and the authentication request message (cG) being carried out if the authentication key (d) is validated.

12. Generation method according to the preceding claim, wherein the method includes a step of obtaining the authentication request message (cG) if the authentication key (d) is validated.

13. Generation method according to any one of claims 3 to 12, wherein the authentication key (d) is further generated from validation information (v).

14. Generation method according to claim 1, wherein the generation of the authentication information (TOKEN) comprises a step of generating an authentication key (d) from the N private keys associated with the N symbols of the acquired secret information (p), the authentication request message (cG) and the private key associated with the given attribute (d'); the authentication information (TOKEN) is generated from the generated authentication key (d).

15. Generation method according to the preceding claim, wherein the authentication information (TOKEN) is further generated from validation information (v).

16. A generation method according to any one of the preceding claims, wherein in the set of private keys associated with the symbols of the virtual keyboard, a private key is associated with each symbol of the keyboard and with each possible position of the symbol in the input of secret information.

17. A generation method according to any one of the preceding claims, wherein the authentication request message (cG) is a public parameter or a random or pseudo-random number or a coordinate of an elliptic curve point or a challenge public key.

18. Generation method according to any one of claims 2, 13 or 15, wherein the validation information (v) is a validation private key (v).

19. Generation method according to the preceding claim, wherein a number of usage occurrences is associated with the validation private key (v), the validation private key (v) being regenerated when the number of usage occurrences of the validation private key has reached a given threshold.

20. Generation method according to claim 1, wherein the method includes a step of obtaining the authentication request message (cG) from the third-party device.

21. Individual device configured to implement at least part of the method according to any one of the preceding claims.

22. System comprising a personal device and a hardware security module (HSM) connected to the personal device, the system being configured to implement at least part of the method according to any one of claims 1 to 20.

23. Computer program comprising instructions that cause an individual device to perform at least part of the steps of the process according to any one of claims 1 to 20.

24. Computer-readable medium on which the computer program according to the preceding claim is stored.

5. System comprising an individual device (102) according to claim 21 and a third-party device (104) capable of verifying authentication information (TOKEN) generated by the individual device.

Images