Method of disclosing a PIN code to a user

Abstract

A method for disclosing a PIN to a user, the PIN being intended to be used in combination with a hardware authentication token, such as a smart card, configured to condition access to a service on knowledge of the PIN, the method comprising the following steps implemented by a hardware decryption token: receiving (4.10, 4.15) a ciphertext (C) of the PIN, the ciphertext of the PIN being previously transmitted by a storage server to a user terminal, and then transmitted by the terminal to the hardware decryption token; decrypting (4.12, 4.17) the ciphertext (C) of the PIN so as to recover the PIN; and sending (4.13, 4.18) to the terminal output data dependent on the PIN, the terminal being configured to deduce the PIN from the output data and to display the PIN on a display screen of the terminal. Figure for the abridged version: Fig. 5

Description

Title of the invention: Method for disclosing a PIN code to a user. Scope of the invention

[0001] The present invention relates to a method of disclosing a PIN code to a user. STATE OF THE ART

[0002] A PIN (Personal Identification Number) is a security code made up of numbers, used to authenticate the user of a bank card, SIM card, or smart card. For example, a PIN protects access to a bank account when a bank card is used for a withdrawal or payment. Without this PIN, it is impossible to carry out transactions, which helps prevent fraud.

[0003] A recurring problem is users forgetting their PIN. In the banking sector, the rise of neo-banks has led to an increase in the number of bank cards held by users; this problem of forgetting therefore tends to occur more frequently.

[0004] To address this problem, a PIN disclosure method is known that allows cardholders to obtain their bank card PIN (initially or as a reminder) directly on their bank's application or website. This method works as follows. PINs are stored by a server in a database not in plain text but in encrypted form (this is a security requirement imposed by certain standards, notably the PCL CPP standard). When a cardholder wishes to view their PIN, a secure device, generally referred to as an HSM (Hardware Security Module) in the literature, is used by the entity managing the server to decrypt the encrypted PIN stored in the database; the PIN is then transmitted to the user, for example, to their smartphone.

[0005] However, an HSM is an expensive piece of equipment. Description of the invention

[0006] One problem to be solved is to limit the cost of the hardware resources used by the entity that manages the storage of PIN codes in a context of disclosing a PIN code to a user who requests it, without loss of security.

[0007] This problem is solved by a method of disclosing a PIN to a user, the PIN being intended to be used in combination with a hardware authentication token, such as a smart card, configured to condition access to a service on knowledge of the PIN, the method comprising the following steps implemented by a hardware decryption token: receiving an encrypted version of the PIN, the encrypted version of the PIN being previously transmitted by a storage server to a user terminal, then transmitted by the terminal to the hardware decryption token; decrypting the encrypted version of the PIN so as to recover the PIN; and sending to the terminal an output data dependent on the PIN, the terminal being configured to deduce the PIN from the output data and to display the PIN on a display screen of the terminal.

[0008] The proposed process, which is the first subject of this disclosure, may further include the following features, taken alone or combined with each other whenever technically possible.

[0009] Preferably, the decryption of the PIN code is carried out using a decryption key forming an asymmetric key pair with an encryption key which was used to produce the ciphertext of the PIN code.

[0010] Preferably, the method further comprises the following steps implemented by the hardware decryption token: receiving a proof password in association with the ciphertext of the PIN code; verifying the correspondence between the proof password and a password stored by the hardware decryption token, in which the output data is sent to the terminal provided that the proof password and the stored password match.

[0011] Preferably, the hardware decryption token is the hardware authentication token.

[0012] Preferably, the encrypted PIN code is received via a wireless communication channel established between the decryption hardware token and the terminal, for example a near field communication channel, NFC, and the output data is sent in the wireless communication channel.

[0013] In one embodiment, the output data is the PIN code.

[0014] In another embodiment, the method further comprises, after the decryption, an encryption of the PIN code by the hardware decryption token using an encryption key forming an asymmetric key pair with a decryption key held by the terminal, so as to produce the output data.

[0015] Preferably, the encryption key used by the hardware decryption token is a one-time-use key that has been generated by the terminal and then provided to the hardware decryption token so as to be used only for decrypting the ciphertext of the received PIN code.

[0016] Preferably, the storage server implements the following steps: receiving a PIN disclosure request associated with an identifier specific to the hardware decryption token; identifying, in a database associating encrypted and hardware token identifiers for decryption, of the encrypted PIN code using the identifier; and sending the encrypted PIN code to the terminal.

[0017] A second subject of this disclosure is a computer program product comprising program code instructions for executing the steps of the process that constitute the first subject of this disclosure, when that program is executed by at least one processor.

[0018] A third object of the present disclosure is a hardware decryption token for disclosing a PIN to a user, the PIN being intended to be used in combination with a hardware authentication token, such as a smart card, configured to condition access to a service on knowledge of the PIN, the hardware decryption token comprising: a communication interface suitable for receiving an encrypted version of the PIN, the encrypted version of the PIN being first transmitted by a storage server to a user terminal, and then transmitted by the terminal to the hardware decryption token; and at least one processor configured to: decrypt the encrypted version of the PIN so as to recover the PIN, and to cause the terminal to be sent, via the communication interface, with output data dependent on the PIN, so that the terminal can deduce the PIN from the output data and display the PIN on a display screen of the terminal.

[0019] A fourth subject of this disclosure is a system comprising: the hardware decryption token constituting the third subject of this disclosure; and a storage server configured to: receive a PIN disclosure request associated with an identifier specific to the hardware decryption token, identify, in a database associating ciphertexts and identifiers of hardware decryption tokens, the ciphertext of the PIN from the identifier, and send the ciphertext of the PIN to the terminal. DESCRIPTION OF THE FIGURES

[0020] Other features, objectives and advantages of the invention will become apparent from the following description, which is purely illustrative and not limiting, and which should be read in conjunction with the accompanying drawings on which:

[0021] Fig. 1 schematically illustrates a system comprising in particular a hardware decryption token and a terminal.

[0022] Figure 2 schematically illustrates internal components of the hardware token decryption and terminal, in one embodiment.

[0023] Fig. 3 is a flowchart of steps of a process for personalizing a physical decryption token, according to one embodiment.

[0024] Figure 4 is a flowchart of steps in the PIN code storage process according to two alternative modes of implementation.

[0025] The [Fig.5] is a flowchart of steps in PIN code disclosure processes according to two alternative embodiments.

[0026] Throughout the figures, similar elements bear identical references. DETAILED DESCRIPTION OF THE INVENTION

[0027] Figure [1] shows a hardware decryption token 1, a user terminal 2, a token management server 4 and a PIN code storage server 6.

[0028] With reference to [Fig.2], the hardware decryption token 1 is a device comprising a communication interface 10, a memory 12 and at least one processor 14.

[0029] The communication interface 10 is preferably of the wireless radio type, for example NFC (“near field communication”). The communication interface 10 is bidirectional, in the sense that it allows data to be sent and received.

[0030] Memory 12 is suitable for storing received data, as well as one or more programs A, B comprising code instructions.

[0031] For example, the hardware decryption token 1 is a smart card; the aforementioned programs are in this context applets A, B. Memory 12 stores in particular a disclosure applet A, the operation of which will be detailed later.

[0032] The processor or processors 14 are adapted to execute the disclosure applet A, and any other applet B present in memory 12.

[0033] A function provided by the hardware decryption token 1, and more particularly by the disclosure applet A, is to participate in the disclosure of a PIN code to a user.

[0034] The PIN is intended to be used by the user in combination with a hardware authentication token configured to condition access to a service upon knowledge of the PIN. To this end, the authentication token includes at least one processor configured to execute an authentication cmdlet. According to a first example, the authentication cmdlet generates a signature by signing data and sends the signature to a terminal. In this example, a proof code is typically entered on the keyboard of a terminal communicating with the authentication token, and the terminal sends the proof code along with the signature to a server configured to verify a match between the proof code and the PIN. Access to the resource or service in question is granted provided that the server concludes that there is a match between the PIN and the proof code, and that the signature is valid.It should be noted that this correspondence check, which is known from the prior art, can be carried out without requiring a . storage of the PIN code in a memory of the authentication token (although this storage remains possible).

[0035] According to a second example, the authentication applet verifies a match between a PIN stored in the authentication token's memory and a proof code, the proof code being, for example, entered on the keyboard of a terminal communicating with the authentication token. In this second example, access to the resource or service in question is authorized provided that the processor concludes that there is a match between the PIN and the proof code.

[0036] For example, the authentication hardware token is a smart card, for example a biometric identity document or a bank card. When the authentication hardware token is a bank card, the service can be a banking transaction.

[0037] In one embodiment, the authentication hardware token is the decryption hardware token 1 itself. In this embodiment, token 1 comprises at least two applets: a disclosure applet A, which is used to disclose a PIN to a user, and an authentication applet B, which verifies that a proof PIN matches a stored PIN. In this embodiment, the stored PIN that the authentication applet compares with the proof PIN is located in a memory area that is preferably not accessible by disclosure applet A. Thus, applets A and B operate independently of each other.

[0038] In another embodiment, the authentication token and the decryption token constitute two separate devices, for example two separate smart cards.

[0039] Terminal 2 includes a first communication interface 20 for communicating with the hardware decryption token 1, a second communication interface 21 for communicating with the token management server 4, a memory 22, at least one processor 24 and a display screen 26.

[0040] The first communication interface 20 is adapted to establish a communication channel with the communication interface 10 of the decryption token 1.

[0041] The second communication interface 21 is of any type, for example wired (Ethernet) or wireless radio (cellular, such as 3G / 4G / 5G, Wi-Fi, Bluetooth or other).

[0042] Memory 22 stores, in particular, an application. This application is provided by an entity exercising control over the token management server 4. This entity is, for example, a bank, in which case the application is a banking application, allowing a user to manage their authentication token and / or their associated bank accounts using terminal 2.

[0043] The application is a program comprising code instructions executable by the or each processor 24 of terminal 2. The role of the application will be described later.

[0044] The token management server 4 is administered by a service provider. In particular, a service provided by the service provider is the PIN-secured service discussed earlier. The service provider is, for example, a bank, and the service is a banking transaction. When the hardware authentication tokens are smart cards, this server is generally called a CMS, for Card Management System.

[0045] The token management server 4 includes a memory storing a database associating token identifiers and their respective passwords.

[0046] The storage server 6 comprises a communication interface, memory containing a database, and at least one processor. The storage server 6 may be administered by an entity separate from the service provider.

[0047] The database contains encrypted PIN codes respectively associated with hardware token identifiers.

[0048] The communication interface of storage server 6 is adapted to communicate with the token management server.

[0049] A process using the devices 1, 2, 4, 6 described above comprises the following phases: • Customization of the hardware decryption token 1, • Storing an encrypted PIN code on storage server 6, • Disclosure of the PIN code to a user U on terminal 2 by making the request. Customizing the decryption token

[0050] With reference to [Fig.3], the personalization includes the following steps in one embodiment.

[0051] In step 1.1, a user U of terminal 2 requests a decryption token for personal use. User U makes this request by interacting with the application on terminal 2. Alternatively, user U could make this request by interacting with another device, for example, an ATM or a kiosk.

[0052] In a step 1.2, the terminal application 2 (or more generally the device with which the use interacts) commands the sending of an RC token request to the token management server 4.

[0053] Token management server 4 receives the RC token request.

[0054] The token management server 4 generates a password P and, if applicable, a token identifier ID associated with the RC request.

[0055] The management server 4 stores in its memory the password P in association with the token identifier ID.

[0056] In a step 1.3, the token management server 4 sends the following data to a personalization center 8: the RC request, with the pass mode P and, where applicable, the associated token ID.

[0057] At the personalization center 8, a pair K of asymmetric keys is generated using a suitable generator in a step 1.4. The key pair K comprises an encryption key Kpublic and a decryption key Kprivate.

[0058] The key pair K is, for example, a pair of RSA keys or keys from an elliptic curve cryptographic algorithm. Alternatively, the key pair K is a pair of post-quantum (PQ) cryptographic keys. Encryption / decryption operations with such keys are more resistant to attacks carried out using a quantum computer than with RSA keys or keys from an elliptic curve cryptographic algorithm.

[0059] In a step 1.5, the decryption token 1 is personalized and then provided to the user U. This personalization includes, in particular, writing the decryption key Kprivate, the password P, and the disclosure applet A into memory 12. Encrypted PIN code storage

[0060] With reference to [Fig.4], storing an encrypted PIN code in the storage server 6 comprises the following steps.

[0061] In step 2.1, an encryptor from the personalization center 8 is used to encrypt a previously chosen PIN code using the encryption key Kpublic. The result of this step is a cipher of the PIN code, denoted C. In [Fig. 4], the encryption function used is denoted "cipher()".

[0062] In a step 2.2, the encrypted PIN code C is sent from the personalization center 8 to the storage server 6, with the token ID that had been previously provided by the token management server 4.

[0063] Also sent in this step is a BID identifier specific to the service provider that administers the token management server 4 and that provides the service secured by the PIN code.

[0064] In a step 2.3, the storage server 6 stores, in its database, the encrypted PIN code C in association with the ID and BID identifiers.

[0065] The ID identifier allows the decryption token 1 to be identified among other tokens, including other decryption tokens. The BID identifier allows the service provider administering server 4 to be distinguished from other service providers. Thus, the same database can be used to store PIN ciphers relating to services provided by different service providers, for example several banks.

[0066] Steps 2.1, 2.2 and 2.3 constitute a first embodiment.

[0067] A second embodiment replacing this first embodiment comprises the following steps.

[0068] In a step 3.1, the Kpublic encryption key is sent from the personalization center to the token management server 4.

[0069] In a step 3.2, the token management server 4 encrypts a PIN code with the encryption key public key K, so as to obtain the cipher C of the PIN code.

[0070] In a step 3.3, the token management server 4 sends the encrypted PIN code C along with the token ID and the BID specific to the service provider that provides the PIN-secured service, as discussed previously.

[0071] In a step 3.4 (identical to step 2.3), the storage server stores, in its database, the encrypted PIN code in association with the ID and BID identifiers.

[0072] Thus, the two embodiments differ from each other, notably with regard to the entity that encrypts and sends the PIN code to the service provider. It is understood that the ID and BID identifiers are sent to the personalization center in the first embodiment, but that this transmission is not necessary in the second embodiment. Disclosure of PIN code to a user

[0073] With reference to [Fig.5], PIN code disclosure includes the following steps.

[0074] In step 4.3, the application on terminal 2 detects a user action on terminal 2 that reveals that user U is requesting the disclosure of the PIN code associated with their authentication token. This action generally involves pressing a dedicated button in the application's graphical interface.

[0075] In a step 4.4, carried out when the application detects this user action, the application commands terminal 2 to send a PIN code disclosure RP request to the token management server.

[0076] The token management server receives the RP request issued in step 4.4.

[0077] From the RP request, the token management server 4 determines the password P and the ID identifier specific to the decryption token 1 associated with the sender of the RP request.

[0078] Generally, the RP request includes information enabling the token management server 4 to identify, in the database contained in its memory, the password P and the identifier ID stored in mutual association. Typically, the token management server 4 can store the information in question in association with a password P and an identifier ID stored in mutual association, for example during a process such as described in [Fig.4].

[0079] In one embodiment, the information in question includes an identifier for the hardware authentication token, for example, the last four digits of the PAN. The information may also include an expiration date for the hardware authentication token (particularly when this hardware authentication token is a bank card) or a proprietary identifier managed by the service provider. For example, the terminal 2 application can be configured to present the user with a visual representation of the hardware authentication tokens that have been assigned to them, and offer them the option of selecting one of these visual representations. The terminal application then sends the proprietary identifier associated with the selected authentication token in the RP request.

[0080] In a step 4.5, the token management server 4 transmits the RP disclosure request with the ID, BID identifiers.

[0081] Storage server 6 receives the request issued in step 4.5.

[0082] The storage server 6 searches and selects, in the associative database cipher PIN codes with respective identifiers, an cipher of a PIN code which is associated with the ID identifier received with the RP request, having been provided by the token management server.

[0083] If the storage server manages multiple service providers, the server can also use the BID identifier when searching.

[0084] In a step 4.6, the storage server 6 sends to the token management server 4 the encrypted PIN code C found in the database.

[0085] In step 4.7, the token management server transmits to terminal 2 the encrypted PIN code C, along with the password P that it has determined. It should be noted that the determination of the password P by the token management server can be implemented at any time after step 4.4 and before step 4.7.

[0086] Terminal 2 receives the encrypted PIN code and the P password mode.

[0087] In step 4.8, the application controls the display on the display screen 26 of terminal 2, a message inviting the user to put the decryption hardware token 1 in communication with terminal 2. For example, if the communication interface 10 of the decryption hardware token 1 is of type NFC, this message may invite the user to place the decryption hardware token 1 near the terminal, in order to establish a wireless communication channel between them.

[0088] The application detects that this communication channel is established with the hardware decryption token 1 (step 4.9).

[0089] In a step 4.10, the application instructs the terminal to send a request to the decryption hardware token 1, via the established communication channel, in RD decryption of the ciphertext C of the PIN code. This decryption request is thus accompanied by the ciphertext of the PIN code, as well as the password P.

[0090] This data is communicated to the disclosure applet A included in the decryption hardware token 1.

[0091] In a step 4.11, applet A checks for a match between the received password P and the password that was stored in the memory of the decryption token during its prior personalization.

[0092] If the two compared passwords match, the applet proceeds to step 4.12. Otherwise, the applet does not implement step 4.12, and may in this case return an error to the terminal via the communication channel.

[0093] This password verification step P improves the security of the disclosure process, compared to a process that does not perform this step. Indeed, if an attacker were to gain access to the database of storage server 6, for example, they would still not be able to obtain the PIN code because they would still lack the password P.

[0094] At step 4.12, applet A decrypts the ciphertext C of the PIN code using the decryption key Kprivate stored in memory 12. The result of this decryption is the PIN code (in plaintext).

[0095] In a step 4.13, applet A instructs communication interface 10 to send the PIN code to terminal 2, via the communication channel established previously.

[0096] Terminal 2 receives the PIN code in plain text.

[0097] In a step 4.20, the application commands the display of the PIN code on the display screen 26 of terminal 2.

[0098] User U of terminal 2 can thus find out the PIN code by observing the display screen 26.

[0099] Steps 4.10 to 4.13 constitute a first embodiment of the processing carried out by the disclosure applet A. We will now describe a second embodiment which is also represented in [Fig.5].

[0100] In step 4.14, the terminal 2 application generates a second key pair L (distinct from the key pair K used to obtain and decrypt the ciphertext of the PIN). The second key pair comprises a public key Lpublic and a private key Lprivate.

[0101] In step 4.15, the application instructs terminal 2 to send the decryption hardware token 1, via the established communication channel, the decryption request RD of the ciphertext of the PIN. The decryption request RD is accompanied by the ciphertext C of the PIN, the password P, and the public key Lpublic. This step 4.15 therefore differs from step 4.10 of the first embodiment. described previously by the fact that the Lpublic key is additional data provided to the decryption token 1.

[0102] This data is communicated to the disclosure applet A included in the token 1.

[0103] In a step 4.16 (identical to step 4.11 described previously), the applet A checks for a match between the received password P and the password that was stored in the memory of the decryption token during its prior personalization.

[0104] If the two compared passwords match, the applet proceeds to step 4.17. Otherwise, the applet does not implement step 4.17, and may in this case return an error to terminal 2 via the communication channel.

[0105] In step 4.17 (identical to step 4.12), applet A decrypts the ciphertext of the PIN code using the decryption key Kprivate stored in memory 12 of the decryption token 1. The result of this decryption is the PIN code (in plaintext). Next, applet A re-encrypts the PIN code, but this time using the public key Lpublic provided by terminal 2. Thus, the result of this step is a second ciphertext C' of the PIN code, different from the ciphertext C that was initially stored by the PIN code storage server.

[0106] In a step 4.18, applet A instructs communication interface 10 to send the second cipher C' of the PIN code to terminal 2, via the communication channel established previously.

[0107] The terminal receives this second cipher C'.

[0108] In a step 4.19, the terminal 2 application decrypts the second ciphertext C' using the private key Lprivate, which allows it to recover the plaintext PIN code.

[0109] The display step 4.20 is then implemented as in the first embodiment.

[0110] Ultimately, in both embodiments discussed, terminal 2 receives output data from the decryption token, from which the terminal can deduce the PIN. In the first embodiment, this output data is the PIN itself. In the second embodiment, this output data is the second ciphertext C', and the application on terminal 2 deduces the PIN by decrypting this second ciphertext using the private key Lprivate that terminal 2 possesses.

[0111] Preferably the key pair L is for single use only (for a single disclosure of PIN code).

[0112] The second embodiment, however, provides an additional level of security, as it protects against attacks that would consist of inspecting the data transmitted through the communication channel established between the decryption token 1 and terminal 2 (whose PIN code is in plain text in the first embodiment). Other ways of implementing this

[0113] Up to this point, embodiments have been described in which the ciphertext C passes through the token management server 4 before reaching terminal 2; in other words, the ciphertext C is transmitted indirectly from the storage server 6 to terminal 2, via the token management server 4. However, this is not mandatory. In other embodiments, the ciphertext C can be transmitted directly from the storage server 6 to terminal 2 (without passing through the token management server 4).

[0114] In one embodiment, the decryption token 1 may be a biometric identification token. This biometric identification token includes a biometric sensor, for example, a fingerprint sensor. The authentication token may only allow the establishment of the communication channel with the terminal if there is a match between a proof biometric data point, acquired by the biometric sensor, and a reference biometric data point stored by the decryption token.

[0115] Up to now, embodiments have been described in which the PIN code is encrypted and then decrypted using an asymmetric key pair. In another embodiment, symmetric cryptography is used as follows: • In step 2.1, the PIN code is encrypted using a symmetric key. • The symmetric key is divided into two key parts: a first part of key, and a second portion of key. • The PIN storage server stores the first part of the key, in association with the encrypted PIN code. • The second part of the key is stored by the decryption token. • In steps 4.6, 4.7 and 4.10 / 4.15, the server transmits the second portion of key with the encrypted PIN code. • At step 4.12 / 4.17, the applet reconstructs the symmetric key from the first portion stored in the decryption token and the second portion of the key provided by the PIN management server, before using this symmetric key to decrypt the ciphertext of the PIN code.

[0116] In another embodiment: • In step 2.1, the PIN code is encrypted using a symmetric key S. • The asymmetric key Kprivate is stored by the decryption token. • The PIN storage server stores an encrypted version of the key symmetric S using the asymmetric key Kpublic, in association with the encrypted PIN code. • At steps 4.6, 4.7 and 4.10 / 4.15, the server transmits the ciphertext of the symmetric key S with the ciphertext of the PIN code. • At step 4.12 / 4.17, the applet decrypts the ciphertext of the symmetric key S using the asymmetric key Kprivate, before using the symmetric key S to decrypt the ciphertext of the PIN code.

[0117] In another embodiment: • The decryption token holds a master symmetric key. • A passphrase is provided to the user. • The encryption key used in step 2.1 is a secondary key derived from the primary symmetric key using the passphrase. • The user is prompted to enter the passphrase, typically on terminal 2, and the entered passphrase is passed to the decryption token along with the other data. • The decryption token obtains the secondary key by applying the same derivation processing, from the primary symmetric key and the entered passphrase. • In step 4.12 / 4.17, the applet uses the secondary key thus obtained to decrypt the ciphertext of the PIN code.

[0118] In another embodiment: • The decryption token includes a biometric sensor (e.g., a fingerprint sensor). • The user is pre-enrolled, meaning that a biometric template of the user, obtained using the biometric sensor or another biometric sensor, is obtained. This biometric template is used as a symmetric key to encrypt the PIN in step 2.1 and to decrypt its ciphertext on the applet side. The user undergoes a biometric test using the biometric sensor before the ciphertext PIN is decrypted. This decryption is only performed if the test is successful, typically if a biometric data point from the user, newly acquired using the biometric sensor during the test, matches the user's biometric template.

[0119] Typically, the biometric template is stored in a memory of the hardware decryption token.

[0120] Despite its security advantages, the use of the password P in the process remains optional.

Claims

Demands

1. A method for disclosing a PIN to a user, the PIN being intended for use in combination with a hardware authentication token, such as a smart card, configured to condition access to a service on knowledge of the PIN, the method comprising the following steps implemented by a hardware decryption token: • receiving (4.10, 4.15) a ciphertext (C) of the PIN, the ciphertext of the PIN being first transmitted by a storage server to a user terminal, and then transmitted by the terminal to the hardware decryption token, • decrypting (4.12, 4.17) the ciphertext (C) of the PIN so as to recover the PIN, • sending (4.13, 4.18) to the terminal output data dependent on the PIN, the terminal being configured to deduce the PIN from the output data and to display the PIN on a display screen of the terminal.

2. A method according to the preceding claim, wherein the decryption (4.12, 4.17) of the PIN code is carried out using a decryption key forming an asymmetric key pair with an encryption key having been used to produce the ciphertext of the PIN code.

3. A method according to any one of the preceding claims, further comprising the following steps implemented by the decryption hardware token: • receiving a proof password in association with the ciphertext of the PIN code, • checking for a match (4.11,4.16) between the proof password and a password stored by the decryption hardware token, • wherein the output data is sent to the terminal provided that the proof password and the stored password match.

4. A method according to any one of the preceding claims, wherein the decryption hardware token is the authentication hardware token.

5. A method according to any one of the preceding claims, wherein the encrypted PIN code is received via a wireless communication channel established between the decryption hardware token and the terminal, for example a near-field communication channel, NFC, and the output data is sent in the communication channel without

6. in. Method according to any one of claims 1 to 5, wherein the output data is the PIN code.

7. A method according to any one of claims 1 to 5, further comprising: • after decryption, encryption of the PIN code by the decryption hardware token using an encryption key forming an asymmetric key pair with a decryption key held by the terminal, so as to produce the output data.

8. A method according to the preceding claim, wherein the encryption key used by the hardware decryption token is a one-time-use key generated by the terminal and then provided to the hardware decryption token so as to be used only for decrypting the ciphertext of the received PIN.

9. A method according to any one of the preceding claims, wherein the storage server implements the following steps: • receiving a PIN disclosure request associated with an identifier specific to the hardware decryption token, • identifying, in a database associating ciphertexts and identifiers of hardware decryption tokens, the ciphertext of the PIN using the identifier, • sending the ciphertext of the PIN to the terminal.

10. Product computer program comprising program code instructions for carrying out the steps of the process according to any one of the preceding claims, when such program is executed by at least one processor.

11. A hardware decryption token (1) for disclosing a PIN to a user, the PIN being intended to be used in combination with a hardware authentication token, such as a smart card,

12. configured to condition access to a service on knowledge of the PIN code, the hardware decryption token includes: • a communication interface (10) suitable for receiving an encrypted version of the PIN code, the encrypted version of the PIN code being previously transmitted by a storage server to a user terminal, then transmitted by the terminal to the hardware decryption token, • at least one processor (14) configured to: • decipher the encrypted PIN code in order to recover the PIN code, • cause the terminal to receive, via the communication interface, output data dependent on the PIN code, so that the terminal can deduce the PIN code from the output data and display the PIN code on a display screen of the terminal. System comprising: • a physical decryption token (1) according to the preceding claim, • a storage server (6) configured for: • receive a PIN disclosure request associated with an identifier specific to the decryption hardware token, • identify, in a database associating ciphertexts and identifiers of hardware decryption tokens, the ciphertext of the PIN code from the identifier • send the encrypted PIN code to the terminal.