Method and device for generating authentication information

Abstract

The invention relates to a method of generating authentication information associated with an individual having a given attribute, a private key being associated with said given attribute (d').The method comprises displaying a virtual keyboard (410) on a user's device (102) for acquiring secret information, the virtual keyboard comprising a plurality b of acquireable symbols, a set of private keys being associated with the symbols of the virtual keyboard, acquiring N symbols (420) 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 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, the private key associated with the given attribute, and an authentication request message transmitted by a third-party device. Abstract figure: Figure 4.

Description

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

[0001] 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. In particular, the invention relates to a method of generating authentication information associated with an individual having a given attribute and the associated individual device.

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

[0003] Figure 1 illustrates a functional diagram 10 of prior art authentication of an individual. In particular, 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 to authenticate itself or to authenticate an attribute of the individual. The individual enters a password or a 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.

[0004] Recent developments aim to decentralize an individual's attributes from the identity provider to the individual's devices. Indeed, today, an individual's attributes are preferably stored in digital wallets, also called identity containers, which are software applications. These software applications are, for example, stored 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 the attributes to be usable, the 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.

[0005] The use of these identity containers therefore allows a decentralization of the attributes of individuals, the latter no longer being stored in centralized servers but being distributed in identity containers stored in identity containers at the level of individuals.

[0006] Such decentralisation implies that there is no longer a central server for the authentication of the attributes of individuals.

[0007] Furthermore, when the individual device is in an operating mode that allows data sharing with a verification device, located particularly near the individual 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.

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

[0009] The object 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.

[0010] This goal is achieved by a method for generating authentication information associated with an individual having a given attribute, a private key being associated with said given attribute. The method comprises the following steps: - displaying a virtual keyboard on an individual's device for acquiring 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, the N acquired symbols forming an acquired secret information; - determination of the N private keys associated with the N symbols of the secret information acquired in the set of private keys associated with the symbols of the virtual keyboard; - generation of 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.

[0011] 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 possession, in particular possession of the device, but also inherence, namely for example through the knowledge of a secret piece of information, for example, a secret code or a password, without however memorizing the secret information.

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

[0013] 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.

[0014] 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 a secret authentication key from the authentication key and the authentication request message and - Authentication information is generated using a cryptographic function from the generated authentication secret key.

[0015] The authentication secret key can be generated by means of at least one shared secret key calculation function from the authentication key and the authentication request message.

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

[0017] 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.

[0018] The cryptographic function may include the application of a message authentication code based on encryption.

[0019] The generation of the authentication key can be carried out using a mathematical function.

[0020] The mathematical function may be a multiplication.

[0021] The method 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 method 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] The 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 may be a public parameter or a random or pseudo-random number or a coordinate of a point on an elliptic curve or a public challenge key.

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

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

[0030] The method 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 process described above.

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

[0033] The invention also relates to a computer program comprising instructions which lead an individual device to execute at least part of the steps of the process described above.

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

[0035] 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.

[0036] 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:

[0037] Fig. 1 illustrates a functional authentication scheme according to the prior art.

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

[0039] Fig. 3 illustrates a functional scheme for the authentication of an individual having an ATT attribute in the system illustrated in Fig. 2.

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

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

[0042] [Fig.6] illustrates a particular embodiment of step 440 of [Fig.4] according to the invention.

[0043] Figure 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.

[0044] [Fig.8] illustrates a particular embodiment of step 740 of [Fig.7] according to the invention.

[0045] [Fig.9] illustrates a particular embodiment of step 440 of [Fig.4] according to the invention.

[0046] [Fig. 10] illustrates another particular embodiment of step 440 of [Fig. 4] according to the invention.

[0047] [Fig. 11] illustrates another particular embodiment of step 740 of [Fig. 7] according to the invention.

[0048] [Fig. 12] illustrates another particular embodiment of step 740 of [Fig. 7] according to the invention.

[0049] [Fig. 13] illustrates another particular embodiment of step 440 of [Fig. 4] according to the invention.

[0050] [Fig. 14] illustrates another particular embodiment of step 740 of [Fig. 7] according to the invention.

[0051] 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 attribute of an individual in accordance with the invention.

[0052] 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. For this purpose, authentication information will be generated in order to be transmitted, in particular via a communication channel, for example short distance from the individual's device to the third party's device and then authenticated.

[0053] 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.

[0054] 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 may 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 may communicate with each other via a communication channel 122. The communication channel is, for example, a wireless communication channel conforming, in particular, to a short-range communication protocol (for example, 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 may 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.

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

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

[0057] 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.

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

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

[0060] The storage space 110 is capable of storing at least one attribute of the individual, such as one or more confidential data or one or more personal data of the individual. Said 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.

[0061] The storage space 110 can further 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.

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

[0063] 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. In 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.

[0064] The storage space 110 of the individual device 102 can further store applications capable of being 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 and which will be described above. The computer program comprises instructions that can be executed at least in part by the processing unit 108, which cause the individual device to execute at least some of the steps of the method for generating authentication information. According to another embodiment, the program computer 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.

[0065] The computer program can be stored in a computer-readable medium. The computer-readable medium may include memory for storing instructions. The memory may include any suitable memory for storing data and executable instructions, such as read-only memory, rewritable flash memory, and a hard drive.

[0066] 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 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.

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

[0068] The third-party device 104 comprises a hardware and software platform on which software runs, this software being either directly executable or interpreted on a virtual machine.

[0069] 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.

[0070] The display device 114 includes in particular an interface of Human-machine communication allows for the display of data and the reception of data from the user of a third-party device. This human-machine communication interface includes, for example, a screen and a keyboard, or a touchscreen.

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

[0072] 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.

[0073] 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 network-type connectivity, either via a wired connection or via a wireless connection (for example, conforming to the Bluetooth standard, the NFC standard, the RFID standard, the Wi-Fi standard (for example, Wi-Fi Direct), or the PC / SC standard). The communication means 120 include, in particular, a module enabling proximity-based communication.

[0074] According to a particular implementation example, communication channel 122 conforms to the NFC standard.

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

[0076] According to the system illustrated in [Fig.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 authentication information TOKEN associated with the individual having a given attribute in accordance with the invention.

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

[0078] This attribute is, for example, the driver's license as illustrated in [Fig.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 individual.

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

[0080] 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's device.

[0081] Upon receipt of 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.

[0082] 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 in accordance with 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.

[0083] Figure 4 illustrates an implementation of the method for generating TOKEN authentication information associated with an individual having a given attribute ATT, according to a first embodiment of the invention. According to the method, a private key is associated with the given attribute of the individual. In the particular embodiment in which the individual has several attributes, for example, 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 a plurality of attributes.

[0084] The method may begin with a step in which the individual device obtains a cG 405 authentication request message. The cG authentication request message may be a public parameter, a random or pseudo-random number, an elliptic curve point G, or a public challenge key. The public challenge key may, 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.

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

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

[0087] The process then continues by displaying a virtual keyboard on the individual's device for the acquisition of secret information (step 410). The display of the A virtual keyboard can be implemented using a graphical interface comprising a virtual keyboard suitable for display on the display device 106 of the individual device 102. The 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.

[0088] Private keys associated with the symbols of the virtual keyboard form a set of private keys associated with the symbols of the virtual keyboard. This set is stored in the individual device 102.

[0089] 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.

[0090] According to another 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 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 comprises 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 having 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.

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

[0092] 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).

[0093] 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 depending on the symbol entered p and according to a particular embodiment, of the position i of the symbol entry.

[0094] The process continues by generating 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.

[0095] According to a particular embodiment, the generation of the TOKEN authentication information may also include one or more other parameters or data.

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

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

[0098] After the generated authentication information (TOKEN) is generated, the individual device 102 can then transmit this authentication information to the third-party device 104, as illustrated in [Fig. 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 may 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.

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

[0100] 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, in particular 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.

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

[0102] 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.

[0103] The N private keys associated with the symbols of the secret information can be transmitted as such from the individual 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.

[0104] An 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 security hardware module HSM.

[0105] 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.

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

[0107] The association operation will now be described.

[0108] In one embodiment, each symbol on the virtual keyboard is associated with a private key Pp. In this embodiment, the assembled data pc is determined, for example, as follows: pC_p. If the assembled data also includes the authentication request message cG, then the assembled data pc is determined, for example, as follows: pC_p cq. Mathematical functions other than multiplication can be used to implement the key association.

[0109] According to another embodiment, each symbol p of the virtual keyboard and each position i of the symbol in the input of the secret information is associated with a private key Pp i. According to this embodiment, the assembled data pc is determined, for example, as follows: pc = FTV n. In the case where the assembled data includes ' 1 / = / pJ also the cG authentication request message, then the assembled pc data is determined for example in the following way: _ rr;V p cq. Others K ■*••*$=! P& Mathematical functions such as multiplication can be used to perform key association.

[0110] 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, the 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 of, an authentication request message cG and a validation information v.

[0111] According to this embodiment, the individual device includes validation information v. The validation information v may be a validation private key v. In this case, a number of usage occurrences may 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 at each execution of the generation process. The number of usage occurrences is incremented after each entry of secret information.

[0112] According to the embodiment illustrated in [Fig.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 of, an authentication request message cG, and the validation information v.

[0113] According to a particular embodiment, the generation of the TOKEN authentication information may also include one or more other parameters or data.

[0114] 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.

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

[0116] 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 in part, 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.

[0117] 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.

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

[0119] 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.

[0120] The N private keys associated with the symbols of the secret information can be transmitted as such from the individual 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.

[0121] An 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 security hardware module HSM.

[0122] 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 of, the cG authentication request message, and the validation information v, or from the assembled data, the private key associated with the given attribute of, 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 in the assembled data). The authentication information generated by the HSM security hardware module is then transmitted to the individual device 102.

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

[0124] According to one embodiment, each symbol on the virtual keyboard is associated with a private key Pp. According to this embodiment, the assembled data pc is determined, for example, as follows: | p . In the case where the assembled data also includes the cG authentication request message, so the data PC assembly is determined, for example, in the following way: nAr ^Pp-cG- determined, for example, in the following way: _ ri v P^ ““ 1 1;_ 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 P cGv ^'other functions Mathematical operations such as multiplication can be used to perform key association.

[0125] According to another embodiment, each symbol p of the virtual keyboard and each position i of the symbol in the input of the secret information is associated with a private key Pp i. According to this embodiment, the assembled data pc is determined, for example, in the following way: _ ||vp . In the case where the assembled data includes also the cG authentication request message, then the assembled data pc is determined, for example, as follows: =IÏA cq. In the case where the assembled data also includes the cG authentication request message and the validation information v, then the assembled data pc is determined by For example, in the following way: _ f|v ». Other mathematical functions that multiplication can be used for key association.

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

[0127] Fig. 9 relates to a particular embodiment of step 440 of Fig. 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 d, and an authentication request message cG.

[0128] According to the embodiment illustrated in [Fig. 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.

[0129] According to a particular embodiment, the step of generating an authentication key d can be preceded by a key association operation, in particular 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 the support of [Fig. 6].

[0130] 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 depends on the symbol's position in 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 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 [Fig.6].

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

[0132] Step 910 can be followed by an optional validation step of the generated authentication key d (step 920). 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 d and the elliptic curve point G.

[0133] 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 [Fig. 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.

[0134] Step 920 is further omitted and step 405 is maintained if the previously described key association operation is carried out using the cG authentication request message.

[0135] 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 [Fig.4].

[0136] The next step illustrated in [Fig.9] is the step of generating the TOKEN authentication information (step 940). The TOKEN authentication information is generated from the generated authentication key d and the authentication request message cG.

[0137] The authentication information JETON can be generated by means of a mathematical function fct2 from generated authentication key d and the authentication request message cG: JETON = fct2(d, cG).

[0138] The [Fig. 10] relating to another particular embodiment of step 440 of [Fig. 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.

[0139] Steps 910, 920 and 930 of [Fig. 10] refer to steps identical to steps 910, 920 and 930 illustrated in [Fig. 9] and described above.

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

[0141] 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.

[0142] 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 the individual's device, then the generated authentication secret key Ks is the key shared with the third-party device, i.e., stored in the third-party device, so that the latter is able to verify the authentication information generated on the individual's device.

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

[0144] According to a 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 by applying a key derivation function to the result of the Diffie-Hellman function. Thus, the authentication secret key Ks is, for example, generated as follows: Ks = KDF(DH(d, cG)) where KDF is a key derivation function and DH is a Diffie-Hellman function.

[0145] According to the process illustrated in [Fig. 10], step 1035 is followed by step 1040 in which the TOKEN authentication information is generated using a cryptographic function from the generated authentication secret key Ks. The TOKEN authentication information can further 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.

[0146] The cryptographic function may include the application of a message authentication code based on encryption, namely, for example, a CMAC. The cryptographic function could also be a hash function.

[0147] 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 individual's ATT attribute from the N private keys associated with the N symbols of the acquired secret information p, of the private key associated with the given attribute d', of an authentication request message cG and of the validation information v.

[0148] According to the embodiment illustrated in [Fig. 1 1], 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.

[0149] According to a particular embodiment, the step of generating an authentication key is preceded by a key association operation, in particular 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 the support of [Fig.8].

[0150] According to another particular embodiment, the key association operation is carried out in the following manner previously described in the support of [Fig.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 [Fig.8].

[0151] The authentication key d is then generated by means of a mathematical function fct3 from the assembled data pc generated, the private key associated with the given attribute d' of the validation information v: d = fct3(pc, v, d').

[0152] 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 the individual D. In this case, the public key associated with the given attribute of the individual D can be stored in the individual's device. According to this embodiment, the public key associated with the given attribute of the 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.

[0153] 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 [Fig. 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.

[0154] Step 1120 is further omitted and step 705 is maintained if the previously described key association operation is carried out using the cG authentication request message.

[0155] 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 [Fig.7].

[0156] The next step illustrated in [Fig. 1 1] is the step of generating the TOKEN authentication information (step 1140). The TOKEN authentication information is generated from the generated authentication key d and the authentication request message cG.

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

[0158] The [Fig. 12] relating to another particular embodiment of step 740 of [Fig. 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, of the private key associated with the given attribute of, of an authentication request message cG of the validation information v.

[0159] Steps 1110, 1120 and 1130 of [Fig. 12] refer to steps identical to steps 1110, 1120 and 1130 illustrated in [Fig. 11] and described above.

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

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

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

[0163] 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.

[0164] 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 the individual's device, then the generated authentication secret key Ks is the key shared with the third-party device, i.e., stored in the third-party device, so that the latter is able to verify the authentication information generated on the individual's device.

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

[0166] According to a particular embodiment, the authentication secret key Ks is generated by applying a Diffie-Hellman function from the key The authentication key d and the authentication request message cG are generated 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(d, cG)) where KDF is a key derivation function and DH is a Diffie-Hellman function.

[0167] According to the process illustrated in [Fig. 12], step 1235 is followed by step 1240 in which the TOKEN authentication information is generated using a cryptographic function from the generated authentication secret key Ks. The TOKEN authentication information can further be generated from an identity signed by the entity that issued the individual's attribute and from one or more data points of the attribute 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.

[0168] The cryptographic function includes the application of a message authentication code based on encryption, namely, for example, a CMAC. The cryptographic function could also be a hash function.

[0169] [Fig. 13] illustrates another particular embodiment of step 440 of [Fig. 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.

[0170] 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 authentication request message cG and the private key associated with the given attribute of d'.

[0171] According to a particular embodiment, the step of generating an authentication key d is preceded by a key association operation, in particular 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 the support of [Fig. 6] or [Fig. 9].

[0172] The authentication key d is then generated by means of 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').

[0173] The next step illustrated in [Fig. 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.

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

[0175] As illustrated in [Fig.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 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] [Fig. 14] illustrates another particular embodiment of step 740 of [Fig. 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 a validation information v.

[0178] 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 authentication request message cG and the private key associated with the given attribute of d'.

[0179] According to a particular embodiment, the step of generating an authentication key d is preceded by a key association operation, in particular 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 the support of [Fig.8] or [Fig.11].

[0180] The authentication key d is then generated by means of 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').

[0181] The next step illustrated in [Fig. 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 d.

[0182] 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).

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

[0184] This transmission may also include the identity signed by the entity that issued the individual's attribute and one or more data items from the attribute that will be disclosed to the third-party device. The signed identity may include data the masked individual's identity, a public key of 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.

[0185] [Fig. 15] corresponds to the system of [Fig. 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.

[0186] As illustrated in [Fig. 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 subsequently.

[0187] 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.

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

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

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

[0191] To perform this authentication, the third-party device 104 has the secret key of challenge c. The secret key of challenge ca allowed the third-party device 104 to generate the authentication request message cG which was transmitted after generation to the individual's device 102 for the generation of the TOKEN authentication information.

[0192] According to a particular embodiment, the challenge secret key c is generated for each new session. Therefore, the cG authentication request message is different for each new session.

[0193] From the public key of the attribute associated with individual D and the secret key of challenge c, the third-party device 104 will generate a verification TOKEN authentication information.

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

[0195] The public key of the attribute associated with the 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.

[0196] 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.

[0197] According to a 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, for example, generated as follows: Ks = KDF(DH(c, D)) where KDF is a key derivation function and DH is a Diffie-Hellman function.

[0198] According to another embodiment, the authentication secret key Ks being shared by the individual 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 that generated by the individual device.

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

[0200] The TOKEN-VERIF authentication information can further be generated from an identity signed by the entity that issued the individual's attribute and from one or more data points of 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 of the attribute associated with individual D, and / or the signature of the signed identity.

[0201] The cryptographic function may include the application of a message authentication code based on encryption, namely, for example, a CMAC. The cryptographic function could also be a hash function.

[0202] The third-party device then verifies that the received TOKEN authentication information is equal to 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. A method for generating authentication information (TOKEN) associated with an individual having a given attribute (ATT), a private key being associated with said given attribute (d1), the method comprising the following steps: - displaying a virtual keyboard (410) on an individual's device (102) 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 from the virtual keyboard, N symbols (p;) (420), the N acquired symbols (p;) forming an acquired secret information (p); - determining 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 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 (d1) and an authentication request message (cG) transmitted by a third-party device.;

2. A generation method according to the preceding claim, wherein the authentication information (TOKEN) is further generated from validation information (v) (740).

3. A 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 (d1); 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 (d1) (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. A 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. A 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. A 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. A 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 validation step of 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. A 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. A generation method according to any one of claims 3 to 12, wherein the authentication key (d) is further generated from validation information (v).

14. 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 N symbols of the acquired secret information (p), the authentication request message (cG) and the private key associated with the given attribute (d1); the authentication information (TOKEN) is generated from the generated authentication key (d).

15. A 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. A generation method according to any one of claims 2, 13 or 15, wherein the validation information (v) is a validation private key (v).

19. A 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

20.

21.

22.

23.

24.

25. the number of occurrences of use of the validation private key has reached a given threshold. Generation method according to claim 1, wherein the method includes a step of obtaining the authentication request message (cG) from the third-party device. Individual device configured to implement at least partially the method according to any one of the preceding claims. System comprising a personal device and a hardware security module (HSM) connected to the personal device, the system being configured to implement at least in part the method according to any one of claims 1 to 20. Computer program comprising instructions that lead an individual device to perform at least some of the steps of the process according to any one of claims 1 to 20. Computer-readable medium on which the computer program according to the preceding claim is stored. 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